If you require a specific version of any package, then you MUST include an Epoch in that dependency. If the Epoch is blank, then make it "0".
Why? Can you give a good reason to introduce "0" in every versionned dependency? I can only think of reasons _not_ to :
- Keep things shorter, clearer thus easier to understand
- Not confuse the user with the arbitrary number that the epoch is when he gets a message like "Failed dependencies, requires foo >= 1.20"
Epochs are only used in corner-cases, why make them appear in the general case at all?
I still don't think introducing a zero epoch everywhere is sensible nor useful.
Matthias
Does RPM not handle epoch value as 0? or am I mistaken? I am of the opinion and understanding that epoch should be avoided at all costs where possible. So not defining it would make more sense than defining it for the sake of doing so, since RPM (still not sure) assumes a 0 value for undefined epoch values.
Mike
Michael Honeyfield wrote:
If you require a specific version of any package, then you MUST include an Epoch in that dependency. If the Epoch is blank, then make it "0".
Why? Can you give a good reason to introduce "0" in every versionned dependency? I can only think of reasons _not_ to :
- Keep things shorter, clearer thus easier to understand
- Not confuse the user with the arbitrary number that the epoch is when he
gets a message like "Failed dependencies, requires foo >= 1.20"
Epochs are only used in corner-cases, why make them appear in the general case at all?
I still don't think introducing a zero epoch everywhere is sensible nor useful.
Matthias
Does RPM not handle epoch value as 0? or am I mistaken? I am of the opinion and understanding that epoch should be avoided at all costs where possible. So not defining it would make more sense than defining it for the sake of doing so, since RPM (still not sure) assumes a 0 value for undefined epoch values.
Mike
We've gone through this a million times, and some people just do not understand. I do not use FreshRPMS so I no longer care that all of those packages are potentially broken when it comes to epoch promotion.
fedora.us had this policy for the last 9 months for a good reason. Just do it, or your package will not be accepted into Fedora Extras.
Warren
Hi! i found around on the internet that it's possible to create a bootable cd to install fedora on ppc througt anaconda... Can u help me? I have no idea on how to make it! Tks
k1n6w4r3z
Warren Togami wrote :
We've gone through this a million times, and some people just do not understand. I do not use FreshRPMS so I no longer care that all of those packages are potentially broken when it comes to epoch promotion.
fedora.us had this policy for the last 9 months for a good reason. Just do it, or your package will not be accepted into Fedora Extras.
Why is that!? No official Red Hat packages have epoch set to 0 (see "rpm -qa --qf '%{epoch}\t%{name}\n'" output), and AFAIK, rpm >= 4.2 treats no epoch as 0. So, as Fedora Extras will probably only start with FC2, and should include guidelines and policies applicable to Fedora Core too, I really don't see the reason to systematically introduce a zero epoch into each and every possible package now. For rpm < 4.2, maybe, but again, it's a little far away now to be an important matter.
Why would I say "Epochs are evil" but go and set them to zero everywhere when it can be sanely avoided now?
I guess we're up to one million and one now.
Matthias
Matthias Saou wrote:
Warren Togami wrote :
We've gone through this a million times, and some people just do not understand. I do not use FreshRPMS so I no longer care that all of those packages are potentially broken when it comes to epoch promotion.
fedora.us had this policy for the last 9 months for a good reason. Just do it, or your package will not be accepted into Fedora Extras.
Why is that!? No official Red Hat packages have epoch set to 0 (see "rpm -qa --qf '%{epoch}\t%{name}\n'" output), and AFAIK, rpm >= 4.2 treats no epoch as 0.
This point also has escaped you, that Epoch: 0 is NOT what we have made mandatory. We have made mandatory that you must NEVER leave epoch out of a versioned dependency. In cases like this:
Requires: libfoo >= 1.0.1
Where libfoo's epoch is blank or zero, you must always instead use:
Requires: libfoo >= 0:1.0.1
rpm has NO WAY of knowing what Epoch is implied during resolving dependencies during an upgrade when it is omitted, and as a result it needs to make an assumption based upon the already installed system. This assumption can be incorrect causing an upgrade failure or package clash. Even Red Hat themselves has grudgingly recognized the necessity of epochs in versioned dependencies.
fedora.us highly recommends also including Epoch: 0 even though it makes no functional difference, mainly as an explicit reminder that zero must be included in the corresponding versioned dependency rather than omitted.
So, as Fedora Extras will probably only start with FC2, and should include guidelines and policies applicable to Fedora Core too, I really don't see the reason to systematically introduce a zero epoch into each and every possible package now. For rpm < 4.2, maybe, but again, it's a little far away now to be an important matter.
You publish a lot more than packages for rpm > 4.2, and to this day those packages still have not observed this necessity. This is not to say that it will cause problems, but it HAS caused problems in the past, and potentially still can. Why not avoid it entirely and observe this simple rule? Slowly phase out the old way as you update your packages.
I have avoided mentioning this about FreshRPMS publically for many months because I felt it would be disrespectful of you and your work, but I cannot allow mistruths about the situation to be propogated.
Again this is not a personal attack. This is the technical matters as I understand it. Unless it is proved that this is not the problem I must continue to insist this. But... what you do with your own repository is entirely your own decision.
Why would I say "Epochs are evil" but go and set them to zero everywhere when it can be sanely avoided now?
Epoch: 0 is not mandatory as its behavior is exactly identical to no epoch, but unfortunately zero must be defined for versioned dependecies in order to completely avoid surprises. This has been demonstrated to not be only a theoretical problem. Refusing to acknowledge it is akin to putting your hands over your ears and not wanting to hear it.
All of us early in our packaging careers learn that "Epochs are evil". It would be so much simpler if that is all we need to believe, but unfortunately it is nowhere near this simple.
Epochs are a necessary evil. We have not designed a feasible way of avoiding Epochs, so we have to live with it the best we can. Fortunately we the fedora.us team seem to have found a codified way of avoiding all potential Epoch problems by following a set of simple rules.
Do not mistake me or fedora.us to be Epoch cheerleaders. Our seemingly onerous and strict naming policies were carefully designed in order avoid the necessity of ever incrementing epoch again due improper package naming. This has happened far too often in the past (i.e. mozilla). fedora.us has designed a way, when followed, avoids Epoch incrementing entirely [1].
Modification of our existing naming guidelines to remove the leading "0.fdr.", using numerical disttags, and moving the optional repository tag to the end, is our recommendation to do the same for future fedora.redhat.com packages.
The other policy regarding epoch-in-versioned-dependencies deals with the necessary evil of Epochs in a completely predictable manner. fedora.us hates Epoch, but we understand it and know how to avoid its evil grasp.
Warren
[1] Epoch incrementing still may happen in the event of needing to downgrade %{version}. But we're generally careful about not pushing a package too soon so we have avoided this thus far.