On Mon, Jan 08, 2007 at 09:41:56AM -0500, Fernando Nasser wrote:
I'd also change the format to "the smallest possible
are already a pain as small integers like "1" or "2". Imagine as
"anything that is suited for the version/release tags is also suited here".
Indeed, that's what I meant. "anything that is suited for the
version/release tags is also suited here" was prefixed with
"technically" meaning that this is what rpm accepts in this field.
Also, I have mixed feeling about this. As there are some packages
for historic reasons had to have their Epoch bumped, it is very easy to
forget to add the "1:" in front of the dependency versions.
Or whatever the epoch is, that's the issue, you always have to look
up. But we shouldn't add "0:" prefixes for the sake of keeping the
epoch mechanism in the packagers' back of the head. On the contrary
epochs should be considered bad mechanisms and not displayed in that
way into conscience.
The other thing is that RPMs deal with "EVR" where
"E" stands for
"Epoch", so I wonder if the right thing wouldn't be to make that
clear by having the Epoch, Version and Release tags all there,
always (even if zero).
Not for zero epochs - I'd even recommend strongly against adding the
Release tag, which is most often not done anyway. There are some rare
cases where you do need the Release tag, though (one example is when a
package was FHSized and one needs to make sure one picks the right
package of the same versions out), but generally that's not needed.
Anyway, before it would be a problem to make this change as RPM had a
bug that would not correctly equate "Epoch: 0" with a version dependency
lacking the leading ":0", but I believe this has been fixed several RPM
releases ago (right Paul?),
This was never a problem with Fedora Core's rpm, the last release
relying on promoteepoch was RHL9. FC1 and RHEL3 and above a
so it shouldn't be a problem now. But please allow a release or
to enforce this so we can propagate this rule upstream to the
packages we import (leaving it as a recommendation only for FC7 for
But this doesn't break anything. It is just a safeguard for not having
new packagers over-epochize their packages and for not considering
epochs as the all-round-no-side-effects saviour for bad versioning
choices, and mostly follows current practice anyhow. Consider it an
educational measure, nothing more.
Also note that other than mandating a simple integer (in case an epoch
is really needed) the suggested changes are a mere recommendation: no
existing package in either repo will become invalid due to that. Still
for someone going thorugh the guidelines for the first time it is
helpful to see what is considered bad practice.
So all in all it is a very conservative change in the guidelines.
Axel Thimm wrote:
>Seems like it isn't really clear that we want packagers to evoid
>epochs like the devil. There are some situations that require epochs,
>when there is no other way to undo versioning and, of course, when
>there were epochs to start with.
>Currently epochs are only mentioned under the Requires section:
>>Second, the Epoch must be listed when adding a versioned dependency
>>to achieve robust epoch-version-release comparison. A quick way to
>>check the Epoch of package foo is to run:
>I'd like to clarify that so that it refers only to non-zero epochs to
>avoid people adding "0:" upfront of every mentioned version(-release),
>e.g. change "the Epoch" against "a non-zero Epoch"
>Then I'd like to have somewhere a recommendation that epochs should be
>avoided as much as possible. This seems to belong to
>Packaging/NamingGuidelines, where epochs seem to have been left off
>(probably deliberately to not lead people into temptation). How about
>>epochs are generally to be avoided. They provide a last-resort
>>mechanism to override package version and release, but are more
>>trouble than they are worth while. If you realy have to use an epoch
>>you MUST use a simple integer (technically anything that is suited
>>for the version/release tags is also suited here). Make sure you
>>explore all other possiblities before deciding to use epochs.
Axel.Thimm at ATrpms.net