Hello all,
Some weeks ago, I encountered some interesting situations regarding
how to deal with mass package upgrades, especially in the case of
distribution renames and ensuring that packages remain in lockstep
with the release installed. Distributions such as Fedora and Mageia
usually solved it by doing some hacking of the Release field to
include a distribution tag. Fedora uses %dist, while Mageia uses
%mkrel.
However, both do not provide a perfect method to represent the
independent package release information in a manner that would
consistently ensure upgrades work without further trickery. For
example, Fedora suggests in its guidelines to do stuff like
1%{?dist}.1 to ensure that when the release was bumped, it would be
upgraded regardless[0]. I've encountered a few cases where we still
have problems with pre-release and post-release snapshots as well,
which has led to FPC tickets and clamors for using ~ and + in the
version field for it.
After a quick search, I found out that there had been a ticket filed
about getting a consistent %dist macro or some equivalent years ago by
Rahul Sundaram[1]. A bit more searching yielded that a distribution
had solved the problem before by simply moving the dist tag
information out of the Release field.
OpenMandriva's version of RPM has a slight tweak to wire up
RPMTAG_DISTTAG to contain their tag ("omv") and added RPMTAG_DISTEPOCH
to contain the distribution release version ("2015.0" in this case).
Version comparison has been tweaked to treat RPMTAG_DISTEPOCH like a
package epoch, which prevents certain kinds of brokenness in exotic
situations, such as distribution renames.
A couple of advantages of this approach: Handling more complex
version/release schemes becomes a lot simpler, and when used properly,
it becomes a lot harder to mix packages that are of different releases
(which can break the system, especially if major ABI changes have
occurred).
The major disadvantage of this approach is that it does add to the
package header more information. However, I consider this a non-issue,
as we already are hacking the Release field to represent the
information, and it isn't represented very well. Another issue would
be that older versions of RPM wouldn't know what to do with it, and
package managers (like DNF) need to be set up to handle the extra
information.
Overall, I think it's a more solid, distribution agnostic approach to
handling distribution release information.
What does everyone else think?
[0]:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_bumps_for_old_branches
[1]: http://rpm.org/ticket/859
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
