On Tue, May 27, 2008 at 9:05 AM, David Mansfield <epel(a)dm.cobite.com> wrote:
For years I've been really happy with the combo of Centos +
DAG/rpmforge. But now that I need EPEL for git rpms, there are a number
of painful conflicts appearing between EPEL and DAG/rpmforge. Since
DAG/rpmforge has been the gold standard for add-ons for years prior to
EPEL, I think it would be great to eliminate these conflicts.
If possible, I'd like to know what I can do to help fix these.
Currently, my issue is with perl-DateTime, but perl-Error has also been
a thorn which was only resolved with some ugly '--force' action.
The perl-DateTime RPM is currently showing 0.41, however it wants to
replace my version from rpmforge which is 0.42.
I don't know why, but when doing a '--provides' on the two packages, the
EPEL one shows:
perl-DateTime = 1:0.41-1.el5
and the rpmforge one shows:
perl-DateTime = 0.42-1.el5.rf
So yum would like to replace this one because of the '1:', I presume.
I'm not even sure what the '1:' indicates.
The 1: is the super-secret-magic EPOCH number. It is the "hidden will
always get upgraded versus anything else" number that allows for
maintainers to get out bad packages but it is also something that will
dog a package from then on.
Its purpose is to allow for a maintainer to downgrade a package in the
case where say "0.38-1" had a major bug in it and could only be fixed
in "0.37-1". The maintainer would have to go with adding the epoch.
The problem is that EPOCH always wins.. so you have to keep it in a
package from then on or move it forward. 1:0.01-1 will always beat
Since EPEL packages are inherited from Fedora, it causes problems in
dealing with compatibility when 'upstream' uses an EPOCH or similar
tool to get past some packaging problem. I will clarify the FAQ about
'encouraging compatibility' to better explain the limits and where
users will trip themselves up.
Also, the rpmforge packaging has split the locale and timezone stuff
into separate packages, whereas the EPEL one hasn't, and this causes
more conflicts for yum.
Any ideas on how to proceed?
epel-devel-list mailing list
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"