Fabio Valentini wrote:
> My reasoning:
>
> There are many reasons why .spec files have to diverge between branches,
> including for:
> - mass rebuilds after branching a new fedora release,
That is a limitation in rel-eng tooling: If a mass rebuild is needed after
branching, it is surely needed in Rawhide too, so what should ideally happen
is that the commit to mass-rebuild in Rawhide should be fast-forward-merged
to the branch (when the branches were in sync before the mass rebuild
commit) instead of bumping the branch separately.
The current mess can be worked around (merge master to the branch, fast-
forward-merge the branch back to the master), but it would be avoidable with
slightly smarter scripting.
> - rebuilds for .soname changes (usually in rawhide),
That's then just a harmless changelog entry. I don't maintain separate
branch changelogs for my packages. The changelog is fully accurate only for
Rawhide, the branches will just have those changes listed even if the build
never happened for the branch. That is not a catastrophe.
Changelog pedantry is not worth losing the convenience of fast-forwarding
the branches.
> - bug fixes / patches specific to a certain branch,
These are rare and can be conditionalized. Most patches make sense to apply
everywhere. Even patches to make the package build with a newer library are
often written in a way that lets the package still build with the older
version too. And the few times it is needed, adding a conditional is easy.
> - changed Packaging Guidelines (for example, due to obsolete scriptlets).
At least within Fedora releases, guideline changes are often only made when
the change works across all supported releases, and IMHO that is how it
should be. We can easily backport changes to required changes to RPM and
redhat-rpm-config in updates. But failing that, conditionals can temporarily
be used, until the old Fedora release goes out of support.
That is more of an issue for EPEL, and I wouldn't object to banning EPEL
conditionals, but banning Fedora conditionals does not make sense and would
likely make me stop maintaining packages in the official Fedora dist-git
entirely.
> All this inevitably leads to diverging %changelogs, Release: tag values -
> and to a lot of conditionals, if the .spec files need to be kept
> "compatible" between branches for some reason.
>
> In my opinion, the benefit of being able to "merge" (in quotes, because
> merging changelogs doesn't work) newer branches into old ones
I don't understand this obsession about changelogs. I just fast-forward-
merge everything from master into the branches, including the changelog. If
it lists some rebuild that only happened in Rawhide, or if it doesn't list
some branch-specific change (after which I usually restore fast-
forwardability using the two-way-merge trick I explained above), so be it.
All the maintainers who keep the branches in sync work that way.
> is dwarfed by the additional burden of maintaining and constantly updating
> all conditionals (which leads to bugs). As Igor mentioned, all rich deps,
> most virtual provides, most scriptlets, etc. have to be wrapped.
Only if you want to support EPEL with the same specfile. I care about fast-
forwardability for Fedora branches only, where that is just not true. (e.g.,
rich deps now just work across all supported Fedora releases).
> As a result, some packagers don't seem to care (or don't have the time) to
> update their packages for changed Guidelines (because adding and
> maintaining all those conditionals correctly is hard, I guess). This leads
> to .spec files for rawhide packages which don't comply with the current
> Packaging Guidelines
I also don't see why this is such a catastrophe. Some of those changes make
no difference whatsoever to end-users and so there's no rush to make them
(e.g., changing some package name BuildRequires to a virtual one), others
are performance improvements of the package update process that are nice,
but not exactly urgent either (e.g., removing some scriptlet in favor of
per-transaction file triggers). Our packages have matured so much by now
that it is rare that packaging guideline changes actually really fix bugs.
> or to bugs or undesired behaviour changes.
And this is why I dislike unnecessary global updates for new cosmetic
guidelines to begin with. And it will happen the same way no matter whether
the change is done conditionally or unconditionally, so I don't see how this
is an issue with conditionals.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
