Michael Jennings wrote:
Yes, it's difficult to guarantee a smooth transition from an rpm made by a different packager if you're not familiar with the versioning scheme of that packager. That's not a problem unique to Epoch, however - you get the same issue with Release and also to a certain extent Version (for instance, your perl 5.00503 could easily be given different rpm versions by different packagers.) And saying no to a smooth transition between rpm versions *from the same packager* because you want to try to get a smooth transition between different packager's rpms, is rather dumb, IMO. I'd rather disallow automatic upgrade from one distribution to another than between different versions of the same, and like I said, the switch is likely to require extra work anyway, so I don't think you should give away upgradeability in its name.On Tuesday, 01 March 2005, at 11:03:35 (+1300), Darryl Dixon wrote:
Get real.
:-)
Using epoch *is* doing it right. Why on earth should potentially
many 1000's of customers be forced to do something manually when the
mechanism already exists to do it automatically (epoch)? Computers
and software exist to work *for* us, not against us, and a stupid
arbitrary rule categorising epoch as 'bad' when doing this causes
real problems for people is just ludicrous. Epoch is useful, solves
a real problem, and isn't particularly hard to live with. What
exactly is the problem?
The problem is that use of epoch completely nullifies package portability. For example:
Crimson Headware, Inc., creates distribution X which is RPM-based and includes perl 5.00503. When perl 5.6.0 comes out, they realize that gross stupidity on the part of the perl packagers has resulted in 5.00503 being interpreted as 5.503, clearly newer than 5.6. Thankfully, epoch saves the day, so their customers can upgrade without manual intervention. Hallelujah.
Crazed Free Software Lunatics, LLC, decides to create their own RPM-based distribution as an alternative to Crimson Headware Linux after the latter decides to start charging 3 quintillion doubloons per CPU. When they start, perl 5.8.1 is current, and the perl packaging deities have (thankfully) realized the error of their ways and will use proper versioning moving forward.
Tragically, CFSL faces the following dilemma: Use Epoch which must not only match the current CH epoch but must also keep in sync with, if not ahead of, theirs; or do not use Epoch and disallow a "yum upgrade" from CH to CFSL.
Then Whacky French Guys Co. arrives on the scene. Repeat ad
infinitum.
Also, if Crazed Free Software Lunatics want to specifically design an rpm to replace Crimson Headware's one, then I don't really see the problem. Obviously, they set *all* version fields accordingly. OK, the presence of Epoch means that's a tiny fraction of extra work because they have to think about 3 fields instead of 2, but I still don't think this makes Epoch that special.
And all this is not much of an argument against Epoch *in general*, I think.
- T
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
