[Fedora-packaging] Re: Guidelines and epochs

Axel Thimm Axel.Thimm at ATrpms.net
Mon Jan 8 15:49:27 UTC 2007

On Mon, Jan 08, 2007 at 10:33:51AM -0500, Fernando Nasser wrote:
> Michael Schwendt wrote:
> >
> >Better would be to keep Epoch out of explicit versioned dependencies
> >completely and rely on Epoch-less "Provides". Example: Instead of doing
> >"BuildRequires: gtk+-devel >= 1:1.2.10" (notice the Epoch) one would do
> >"BuildRequires: gtk+(api) >= 1.2.10" and gtk+-devel would "Provides:
> >gtk+(abi) = %{version}" regardless of its"Epoch: 1" in the package.
> >The Epoch would continue to aid package resolvers.
> >
> This is an interesting concept: use a virtual provides to avoid 
> referring to the Epoch of the package, and yet the Epock will displace 
> old generation ones.
> I wonder if this is possible or convenient in all cases.  We may end up 
> with some ugly virtual provide names in some cases.  But I like the idea 
> in general -- people tend to forget the "1:" prefix.

Please remember what the true use of an epoch is, e.g. to override the
version for whatever reason. If something goes like 1.09, 1.10, then
you need the epoch because rpm sorts differently. And you would need
it for any virtual provides, too.

The reason Michael is proposing to use virtual dependencies is because
at the beginning you think that you can evade epochs. They look like a
secondary version. But unless there is strict control to not mess up
you'll end up in the same scenarios requiring epochs like for
conventional versioning.

E.g. don't get fooled by that trick, it is more papering over than
dealing with epochs. And once you start introducing "second-tier"
epochs the confusion will be perfect.
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20070108/8d54d595/attachment.sig>

More information about the Fedora-packaging mailing list