On Mon, Dec 2, 2019 at 8:28 AM Nicolas Mailhot via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Le 2019-12-02 07:23, Igor Gnatenko a écrit : > > 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 : > > >> > 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. > > Actually, in that case, it would be better to have a foo-1 and foo-2 > package names. That's how the Go macros do it: > 1. major version ends up in the package name name=foo-<major> > 2. if for some stupid reason there is a need for a specific code state > within a major version, name=compat-foo-<major>-<state-ide> > > >> > 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? > > Make the module multibuild thinguie write a generated package list on > each > run; save the list with the module descriptor in a git repo; on next > run, > add everything not re-generated to a modulename-obsoletes package. I meant more how to do it technically, in Koji :) > >> 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 > > That's academic. Downstream users do not get a koji copy, they get a > copy > of produced repos at a particular date. Please don't start shoving into > deep koji corners materials that should end up in package repos. As long > as things exist as Fedora packages, all their build chain must exist in > Fedora package repos (with eventual minor version updates) > > Having all build elements in the package repos themselves is the CORE > feature that makes the “share” community dimension of Fedora work. > Anyone > can take the packages and do whatever he wants with them (audit, > rebuild, > modify), in any rpm build infra (koji, copr, mock, rpmbuild, obs) > without > depending on the Fedora build infra of the year. It would be nice, however please return back to the reality. Many of packages are FTBFS (e.g. some BRs do not exist anymore (due to the dependency update)). So this does not work in practice. It would be cool to get to the point where Fedora repos are self-hosted, but we are quite far from this. > 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
