Disttag for Fedora 7 and beyond

[Michael Schwendt]

On Fri, 5 Jan 2007 13:10:00 +0100, Axel Thimm wrote:

> On Fri, Jan 05, 2007 at 05:44:27AM -0600, Josh Boyer wrote:
> > On Fri, 2007-01-05 at 10:25 +0100, Axel Thimm wrote:
> > > On Fri, Jan 05, 2007 at 09:55:50AM +0100, Michael Schwendt wrote:
> > > > Start using stricter versioning with Epoch bumps as necessary,
> > > 
> > > Ouch! Anything but epochs!
> > 
> > Why?  I keep hearing epochs are the spawn of satan.  It's just a
> > number... why are they so bad?
> 
> If it were just for a per package versioning epochs are just ugly, but
> when it comes to sane versioning of package dependencies you get these
> artificial beasts scattered all around.
> 
> How many packagers have been bitten by Requires: foo >= 2.0.1 while
> they really needed foo >= 17:2.0.1 

Users, not packagers. Years ago, with command-line RPM, when a user
downloaded an arbitrary foo-2.0.1-4.i386.rpm from rpmfind.net in believe
that it need not be for a specific distribution and that it would
install and work fine. A non-obvious hidden Epoch value makes such
users scratch their heads, especially with RPM < 4.1.1. [Similar users
also run into other problems, such as EVR being correct, but SONAME
dependencies being incompatible. Repositories and Add/Remove Software
GUIs to the rescue.]

For everyone else including packagers, in the distribution there is
only one package "foo" with version 2.0.1 or the very latest errata
package in the updates channel. Any yum [or put your favourite package
resolver here] update will pull it in if the system has an older "foo"
with a lower Epoch installed.

If, however, the distribution's repository also contains an older build of
"foo" 3.0, which is broken, the requirement "foo >= 2.0.1" is not specific
enough. You could delete foo 3.0 from the repository, but that would not
result in an automatic downgrade on users' or packagers' machines where
the broken package is still installed.

> and the next update needed at least 23:3.0.
> E.g. the epoch inflation everywhere make it mandatory to start
> checking all your versioned BRs and

Versioned BRs are not affected, since the RPM Epoch never specifies an
API version. You would only BR foo >= 3.0 to satisfy a build requirement,
and that would be both good enough and fragile enough at the same time.
Fragile, because 4.0 might be incompatible, and you cannot avoid using the
Epoch, anyway, if the repository ever contained foo > 3.0 prior to a
non-trivial rollback. 

Just as dist tags are no silver bullet and have their own problems and
pitfalls, epochs are just one mighty tool to something done and be able
to work around a variety of problems.

Epochs are not evil. Even the old explicit "Epoch: 0" policy solved
more problems [of an epoch promotion bug in rpm] than it created, but
is no longer needed. Packagers using dist tags have run into more
pitfalls than packagers using epochs (e.g. with cvs tags, with minor
release bumps, with dist tags on huge noarch data packages, with
superfluous rebuilds only to update the dist tag in the pkg file name,
with quick mass-updates to multiple branches).