On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar <ppisar(a)redhat.com> wrote:
V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
> Have we made sure that when Red Hat forks Fedora packages for RHEL
> that they don't truncate or eliminate the Git history anymore? Because I would
> personally be very displeased if my historical attribution went away
> because of broken processes like the one used to fork all the Fedora
> Linux 34 packages for CentOS Stream 9.
>
It's not only about loosing attributions. There will be NEVRA discrepancies in
RHEL:
Different number of commits will mean different release numbers. That will
break package interdependencies which requires a specific release number. E.g
foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus Fedora foo
will strengthen the dependency with "Requires: bar >= 1-2". However, after
importing to RHEL, bar will become bar-1-1. The dependency from foo will
break.
That's a good point. The design works well within a single,
continuous development environment such as Fedora's but any usage of
the sources outside of that, either by importing SRPMs or by importing
subsets of dist-git, seems like it would struggle. Does something
like OBS suffer from the same issue? Seems it would, but I don't know
much about how OBS works.
Another RHEL problem will be fixes for minor RHEL version. E.g. RHEL
10.0 will
contain foo-1-1, RHEL-10.1 updates to foo-1-2, then RHEL-10.0 backports
the change, preferably as foo-1-1.el10_0.1. However, the generated rpmautospec
schema won't allow it and will produce foo-1-2.el10_0. I foresee RHEL
maintainers to revert rpmautospec to manual numbering for minor RHEL updates.
Or automation grows the ability to support that kind of versioning, if
it were to be used in RHEL.
None of these issues are Fedora issues. But considering the
ecosystems
wholistically, the proposed rpmautospec propotion will add a friction.
Nothing is free, that's for sure :)
josh