On Tue, Nov 26, 2019 at 9:23 PM Nicolas Mailhot via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Le mardi 26 novembre 2019 à 16:58 +0100, Igor Gnatenko a écrit : > > Hi, Igor > > > > And we can't actually > > have multiple versions of a package with same name (without "mangled" > > names) in a repo due to the way how our buildsystem works (and not > > only buildsystem, with some caveats). > > I suppose you're talking about filename here, because we certainly have > packages that provide the same thing today. Anyway, this looks a lot > less complex to fix than all the complexity modularity has already > created. No, I am talking about package name here. Koji always takes latest build for buildroot per name. So if you build foo-1-1 and then foo-2-1, only the latter one will be in buildroot. Also tools like pungi (compose tool) always takes latest version and nothing else. > > I need to deal with Obsoletes but I > > simply can't continuously add new Obsoletes into the > > fedora-obsolete-packages. > > Then make the module build infra generate a garbage collector rpm per > stream. That's the kind of repetitive thing it's supposed to handle. Do you have some idea how to do that? > Anyway, this kind of package needs to exist and be supported as long as > the resulting repo contains leaf packages built from it. Otherwise, > you're breaking the security audit chain. No, I don't. They still exist in Koji and if needed, it can be "reproduced". It simply keeps packages which were used in buildroot of any build. Definitely it is more complicated than this, but that's how it works in short. > > Are we trying to create > > technologies which would be very extensible and used in other > > distributions instead of solving some specific problems? > > In my experience, solving specific problems should come first. You > won't get any adoption elsewhere without showing some practical benefit > Fedora-side, and chasing all-encompasing mythical beasts is a great way > to burn time and money without ever delivering anything. > > > > > * If desired, packages can depend on a specific stream via Requires: > > stream(nodejs:10) without actually depending on nodejs (this requires > > some small piece of code in libsolv) > > Why the heck would you want that? Packages should not depend on stream > anymore than they depend on a release as a whole. They should depend on > something specifically inside a stream. And that's just a > Requires: something with stream(streamname) yeah, sure. I just wanted to point out that we *can* do that, not that we *need* to actually do it. > > * All standard Conflicts/Requires/Obsoletes/… will simply work > > Yes, please make it back a single unified rpm-level dependency graph > instead of separate module universes that don't behave with one another > or with the main distro stream. > > That would be totally AWESOME > > Regards, > > -- > Nicolas Mailhot > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
