Nicolas Graves <ngra...@ngraves.fr> writes: > 4) The full Guix way > > Most likely : we don't have the manpower in the short term for > going the full guix way, because, and I second Murilo's point here, we > dive in dependency hell quickly with more required efforts than > reasonable (having implemented it myself, despite being quite proud of > it). > > BUT: Maybe antioxidant is still doable. IIRC the hardest was not setting > #:features correctly (I hope IRC). This is because the information about > features required for parent packages is located in parent / dependent > packages, not in child packages. > > Cargo chooses to rebuild everything ; but there is at least another > solution for that : parse all the dependents of a package to record the > different features/versions a package would need to be generated > with. This means when importing, also sinking into crates.io huge > database, but we could construct an inverse cache or something. > And an importer could then generate more than one version of a package, > but several variants, if several variants are indeed required to build > all its transitive parents. >
Are you saying that if two dependents of a package A depend on the same package B, but with different features we need to build B with the union of those features? Is it possible to build B twice or will it conflict with itself when building A? > To be even more precise we could search only in blessed.rs or lib.rs. > But we need to pull that from Rust, with dependents too (and not in Guix > like Antioxidant did). > > This could lead to a channel like we've seen for Emacs packages or CRAN, > generating regularly from complete upstream info, and we could > incorporate piece by piece packages that build in this channel into > Guix. With limitations: the deduplication of packages (having 4-5 > versions of the same package) will probably still be necessary. > > Otherwise there's just a lot of work by hand, we probably would like to > avoid. >
signature.asc
Description: PGP signature
