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). -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
