[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: incompatible packaging between EPEL and DAG/rpmforge

On Tue, May 27, 2008 at 9:05 AM, David Mansfield <epel 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?
> Thanks,
> David
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list redhat com
> https://www.redhat.com/mailman/listinfo/epel-devel-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"

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]