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.
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
Any ideas on how to proceed?
I think the official answer would be to not use these two repo's together. EPEL really shouldn't be used with any other 3rd party repo's.
Obviously this isn't really that realistic. I get around the issue by using the yum priorities plugin. I generally set EPEL as the second highest priority (after the base repo's) and rpmforge later.
Alternately you can also just specify includepkgs for the packages you need from the repo so nothing else gets stepped on.
I think you will likely find the political challenges more difficult to overcome than the technical ones if you're looking to get things sync'd up and nice between the two repo's. :)
Ray
On Tue, 2008-05-27 at 08:13 -0700, Ray Van Dolson wrote:
Any ideas on how to proceed?
I think the official answer would be to not use these two repo's together. EPEL really shouldn't be used with any other 3rd party repo's.
Obviously this isn't really that realistic. I get around the issue by using the yum priorities plugin. I generally set EPEL as the second highest priority (after the base repo's) and rpmforge later.
Alternately you can also just specify includepkgs for the packages you need from the repo so nothing else gets stepped on.
I think you will likely find the political challenges more difficult to overcome than the technical ones if you're looking to get things sync'd up and nice between the two repo's. :)
Hmm. It says in the FAQ that EPEL 'encourages' compatibility, and to file a bug in bugzilla. Are you saying that there are a lot of 'deaf ears' out there?
Specifically, if I solve the problem, how do I feed back the fixes? This list? fedora-devel? Bugzilla?
I'm basically selfish, and I'm not looking to change the world, just my part.
David
On Tue, May 27, 2008 at 12:05:16PM -0400, David Mansfield wrote:
On Tue, 2008-05-27 at 08:13 -0700, Ray Van Dolson wrote:
Any ideas on how to proceed?
I think the official answer would be to not use these two repo's together. EPEL really shouldn't be used with any other 3rd party repo's.
Obviously this isn't really that realistic. I get around the issue by using the yum priorities plugin. I generally set EPEL as the second highest priority (after the base repo's) and rpmforge later.
Alternately you can also just specify includepkgs for the packages you need from the repo so nothing else gets stepped on.
I think you will likely find the political challenges more difficult to overcome than the technical ones if you're looking to get things sync'd up and nice between the two repo's. :)
Hmm. It says in the FAQ that EPEL 'encourages' compatibility, and to file a bug in bugzilla. Are you saying that there are a lot of 'deaf ears' out there?
Specifically, if I solve the problem, how do I feed back the fixes? This list? fedora-devel? Bugzilla?
I'm basically selfish, and I'm not looking to change the world, just my part.
Well, file a bug by all means... I think a lot of maintainers would be interested in maintaining compatibility as well. Search back in the archives however for a bit of the political background on this whole topic. :)
Ray
On Tue, 2008-05-27 at 09:11 -0700, Ray Van Dolson wrote:
On Tue, May 27, 2008 at 12:05:16PM -0400, David Mansfield wrote:
On Tue, 2008-05-27 at 08:13 -0700, Ray Van Dolson wrote:
Any ideas on how to proceed?
I think the official answer would be to not use these two repo's together. EPEL really shouldn't be used with any other 3rd party repo's.
Obviously this isn't really that realistic. I get around the issue by using the yum priorities plugin. I generally set EPEL as the second highest priority (after the base repo's) and rpmforge later.
Alternately you can also just specify includepkgs for the packages you need from the repo so nothing else gets stepped on.
I think you will likely find the political challenges more difficult to overcome than the technical ones if you're looking to get things sync'd up and nice between the two repo's. :)
Hmm. It says in the FAQ that EPEL 'encourages' compatibility, and to file a bug in bugzilla. Are you saying that there are a lot of 'deaf ears' out there?
Specifically, if I solve the problem, how do I feed back the fixes? This list? fedora-devel? Bugzilla?
I'm basically selfish, and I'm not looking to change the world, just my part.
Well, file a bug by all means... I think a lot of maintainers would be interested in maintaining compatibility as well. Search back in the archives however for a bit of the political background on this whole topic. :)
Will do. Next post I'll have something more substantial for people to argue about ;-)
Thanks, David
On Tue, 2008-05-27 at 08:13 -0700, Ray Van Dolson wrote:
I think you will likely find the political challenges more difficult to overcome than the technical ones if you're looking to get things sync'd up and nice between the two repo's. :)
Is it really fair to call it 'political'?
Fedora has a packaging standard, a method for changing that standard, and reasons things become the standard. Is calling a packaging decision 'political' supported by the history?
- Karsten
On Tue, May 27, 2008 at 11:08:16PM -0700, Karsten 'quaid' Wade wrote:
On Tue, 2008-05-27 at 08:13 -0700, Ray Van Dolson wrote:
I think you will likely find the political challenges more difficult to overcome than the technical ones if you're looking to get things sync'd up and nice between the two repo's. :)
Is it really fair to call it 'political'?
Fedora has a packaging standard, a method for changing that standard, and reasons things become the standard. Is calling a packaging decision 'political' supported by the history?
Use whatever term you like. :) Symanteics aside, my impression of the happenings remains the same...
That said, I regret bringing it up as I think most 3rd party repo's are more than happy to work with EPEL to minimize conflicts.
Ray
David Mansfield 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.
looks like epel's pkg inherited an epoch, so rpmforge's package will likely need to use Epoch: 1 as well.
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?
Contact epel maintainer requesting a similar or at least compatible pkg split (potentially with some judicious Obsoletes/Provides). Likewise with rpmforge... compatibility is a 2-way street after all.
-- Rex
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 0:99.99-99.
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
epel-devel@lists.fedoraproject.org