Should there be BuildRequires for perl/libtool/auto*?

[Warren Togami]

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.