Michael Jennings wrote:
On Friday, 11 March 2005, at 20:11:43 (+1300), Darryl Dixon wrote:
Aha! Now I understand. So your primary objection to epoch is that
it overrides sane versioning practises
Exactly. It allows a package of an inferior version to upgrade (read: replace) a package of a superior version and to allow a package of an inferior version to prevent updating to a superior version.
So what about when across a program's lifetime it doesn't follow
this utopia?
This situation requires some manipulation, yes. But only once. After
the old-scheme package is replaced with the new-scheme package, the
problem is solved. There is no need for continuing to drag along the
solution to this (temporary!) problem in perpetuity.
I fail to see how this is "dragging something along". I mean, any more than other RPM fields. After all, the epoch is just another component of the version data. Yes, it's one more piece of information to keep track of, and I agree that's a bit of an issue, I just fail to see why you think it's that special. And the epoch does encode real versioning information (so it's not just a solution to a temporary problem) when there was a change of versioning policy; it tells you that there was actually a whole series of releases before what was number 1 (or 0) according to the Version field.
But in any case, this discussion is somewhat irrelevant. Even if I were to agree that epoch is bad even in the case where there's a change in versioning schemes, I would still think that Maximum RPM misses the point - because it doesn't seem to recognise this (potential) use at all.
- Toralf
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
