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.
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.
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
