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