Following Fabian's blog post re: RPMForge being rebuilt for EL5, I've a question:
Are there any compatibility problems between RPMForge and EPEL? In other words, if I enabled EPEL previously, will I be able to enable RPMForge as well without running into trouble?
On Dec 4, 2007 1:12 PM, Florin Andrei florin@andrei.myip.org wrote:
Following Fabian's blog post re: RPMForge being rebuilt for EL5, I've a question:
Are there any compatibility problems between RPMForge and EPEL? In other words, if I enabled EPEL previously, will I be able to enable RPMForge as well without running into trouble?
RPMForge and EPEL have several conflicting packages, so yes you may run into trouble.
EPEL has stated that playing nicely with other repos is not a goal of theirs. I would consider them a 'single source' repo. If you're using them, don't use any other 3rd party repos.
On Dec 4, 2007 11:01 AM, Jim Perrin jperrin@gmail.com wrote:
EPEL has stated that playing nicely with other repos is not a goal of theirs. I would consider them a 'single source' repo. If you're using them, don't use any other 3rd party repos.
Isn't this a little too harsh? With proper use of the yum priorities plugin, wouldn't it be possible to use stuff from EPEL together with other 3rd party repos?
In any event, let's not start yet another EPEL discussion here. :-)
Akemi
On Dec 4, 2007 2:51 PM, Akemi Yagi amyagi@gmail.com wrote:
On Dec 4, 2007 11:01 AM, Jim Perrin jperrin@gmail.com wrote:
EPEL has stated that playing nicely with other repos is not a goal of theirs. I would consider them a 'single source' repo. If you're using them, don't use any other 3rd party repos.
Isn't this a little too harsh? With proper use of the yum priorities plugin, wouldn't it be possible to use stuff from EPEL together with other 3rd party repos?
I didn't really mean this to be harsh, just my (usually unwanted) assessment.
It's not that they do conflict necessarily, but that the chance for a conflict or bum update is there. Take for example nagios. This package is listed by nagios.org as being distributed via dag/rpmforge, though EPEL has it too. The epel build separates things out far more than they need to be (one package for each plugin). This isn't how rpmforge does it. Now if you install nagios from epel, and you're using rpmforge also, whichever one updates to the latest version first is where you get it from. In this case, it will well and truly hork up your nagios install.
You can (and I do) use both together, but to safely do so, you have to use yum priorities or protectbase, as well as some exclude/include statements to get things to really and truly play nice without the chance for stepping on toes.
If you're careful, you can do this with absolutely no problem whatsoever. Both repos have excellent folks working them. It's the users I don't trust much. There are simply too many folks who want (and somewhat rightly so) to be able to enable a repo with no fuss, get the package they want, and not have to worry about the repositories eating their software later without doing a priority/include/exclude dance.
On Tue, 2007-12-04 at 21:47 -0500, Jim Perrin wrote:
On Dec 4, 2007 2:51 PM, Akemi Yagi amyagi@gmail.com wrote:
On Dec 4, 2007 11:01 AM, Jim Perrin jperrin@gmail.com wrote:
EPEL has stated that playing nicely with other repos is not a goal of theirs. I would consider them a 'single source' repo. If you're using them, don't use any other 3rd party repos.
Isn't this a little too harsh? With proper use of the yum priorities plugin, wouldn't it be possible to use stuff from EPEL together with other 3rd party repos?
I didn't really mean this to be harsh, just my (usually unwanted) assessment.
It's not that they do conflict necessarily, but that the chance for a conflict or bum update is there. Take for example nagios. This package is listed by nagios.org as being distributed via dag/rpmforge, though EPEL has it too. The epel build separates things out far more than they need to be (one package for each plugin). This isn't how rpmforge does it. Now if you install nagios from epel, and you're using rpmforge also, whichever one updates to the latest version first is where you get it from. In this case, it will well and truly hork up your nagios install.
You can (and I do) use both together, but to safely do so, you have to use yum priorities or protectbase, as well as some exclude/include statements to get things to really and truly play nice without the chance for stepping on toes.
If you're careful, you can do this with absolutely no problem whatsoever. Both repos have excellent folks working them. It's the users I don't trust much. There are simply too many folks who want (and somewhat rightly so) to be able to enable a repo with no fuss, get the package they want, and not have to worry about the repositories eating their software later without doing a priority/include/exclude dance.
---- I'm not entirely sold on the 'priorities' concept but I had to implement to fix the issue when I installed horde because of the conflicting pear-pecl cache that Johnny clued me into (again a collision from dag).
But I like dag's upgrades on other stuff (spamassassin to be certain), etc.
Craig
Jim Perrin wrote:
On Dec 4, 2007 1:12 PM, Florin Andrei florin@andrei.myip.org wrote:
Following Fabian's blog post re: RPMForge being rebuilt for EL5, I've a question:
Are there any compatibility problems between RPMForge and EPEL? In other words, if I enabled EPEL previously, will I be able to enable RPMForge as well without running into trouble?
RPMForge and EPEL have several conflicting packages, so yes you may run into trouble.
A distinct possibility, but at least both repos have made commitments at working together to sort out any identifiable incompatibilities, when/if they arise.
EPEL has stated that playing nicely with other repos is not a goal of theirs.
Huh? In fact, work is underway to codify the opposite: http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration
-- Rex
On Wed, 5 Dec 2007, Rex Dieter wrote:
Huh? In fact, work is underway to codify the opposite: http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration
James 2:14-26
-- Russ Herrold
R P Herrold wrote:
On Wed, 5 Dec 2007, Rex Dieter wrote:
Huh? In fact, work is underway to codify the opposite: http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration
James 2:14-26
If you can identify particular cases where collaboration, as outlined in the above policy draft, was not followed, I will personally break out a can of whoop-ass, and work to fix things.
Remember too, collaboration is a two-way street.
-- Rex
On Thu, 6 Dec 2007, Rex Dieter wrote:
R P Herrold wrote:
James 2:14-26
Rex Dieter replied:
If you can identify particular cases where collaboration, as outlined in the above policy draft, was not followed, I will personally break out a can of whoop-ass, and work to fix things.
Remember too, collaboration is a two-way street.
I never got a reply on my attempts in their court (both ML and IRC), which itemized several matters, chapter and verse -- I decline to pollute centos waters, where community works speak.
That your reply ends with a challenge rather shows a reason not to feed trolls, or wrestle with pigs.
-- Russ Herrold
R P Herrold wrote:
Rex Dieter replied:
If you can identify particular cases where collaboration, as outlined in the above policy draft, was not followed, I will personally break out a can of whoop-ass, and work to fix things.
Remember too, collaboration is a two-way street.
I never got a reply on my attempts in their court (both ML and IRC), which itemized several matters, chapter and verse -- I decline to pollute centos waters, where community works speak.
Please, I only want things to be better (and world peace, and a pony), and that can't happen unless folks can out particular cases where collaboration failed (esp on the epel side), so that I can I can try to help.
In the meantime, I'll go digging on epel's list searching for posts made by you.
-- Rex
On Thu, 6 Dec 2007, Rex Dieter wrote:
that can't happen unless folks can out particular cases where collaboration failed (esp on the epel side), so that I can I can try to help.
'outed' in a off list email to Rex
In the meantime, I'll go digging on epel's list searching for posts made by you.
google; site:redhat.com epel herrold
-- Russ Herrold
On Dec 6, 2007 8:34 AM, R P Herrold herrold@owlriver.com wrote:
On Thu, 6 Dec 2007, Rex Dieter wrote:
R P Herrold wrote:
James 2:14-26
Rex Dieter replied:
If you can identify particular cases where collaboration, as outlined in the above policy draft, was not followed, I will personally break out a can of whoop-ass, and work to fix things.
Remember too, collaboration is a two-way street.
I never got a reply on my attempts in their court (both ML and IRC), which itemized several matters, chapter and verse -- I decline to pollute centos waters, where community works speak.
That your reply ends with a challenge rather shows a reason not to feed trolls, or wrestle with pigs.
I would disagree. The gauntlet was laid down with the Bible quote which is:
14What good is it, my brothers, if a man claims to have faith but has no deeds? Can such faith save him? 15Suppose a brother or sister is without clothes and daily food. 16If one of you says to him, "Go, I wish you well; keep warm and well fed," but does nothing about his physical needs, what good is it? 17In the same way, faith by itself, if it is not accompanied by action, is dead.
18But someone will say, "You have faith; I have deeds." Show me your faith without deeds, and I will show you my faith by what I do.
19You believe that there is one God. Good! Even the demons believe that—and shudder.
20You foolish man, do you want evidence that faith without deeds is useless[a]? 21Was not our ancestor Abraham considered righteous for what he did when he offered his son Isaac on the altar? 22You see that his faith and his actions were working together, and his faith was made complete by what he did. 23And the scripture was fulfilled that says, "Abraham believed God, and it was credited to him as righteousness,"[b] and he was called God's friend. 24You see that a person is justified by what he does and not by faith alone.
25In the same way, was not even Rahab the prostitute considered righteous for what she did when she gave lodging to the spies and sent them off in a different direction? 26As the body without the spirit is dead, so faith without deeds is dead.
He was just quoting back what you had said.. in a different format.
[snip away bible quotes]
This is getting way off topic, please consider what you post.
//Morten
On Thu, Dec 06, 2007 at 12:03:51PM -0600, Les Mikesell wrote:
Morten Torstensen wrote:
[snip away bible quotes]
This is getting way off topic, please consider what you post.
Having only one true repository whose name shall not be uttered in the package filenames doesn't remind you of anything?
No. What exactly are you getting at? :)
Seems like this issue is kinda moot at this point... and honestly, although maybe it would have been _nice_ for EPEL to use repotags, I think their thinking is that Fedora and Fedora Extras in the past doesn't use them; they consider themselves "upstream" in a way and are sticking to that same behavior. They also didn't feel that repotags were really a good solution to the problem.
Many discussions and arguments occurred, but in the end this is how it worked out. And if I recall, EPEL did finally agree to use repotags, but ATrpms had already removed all repotags from their packages so the driving reason to do it was at that point gone.
It's unfortunate, but doesn't seem like it's going to change. I guess that doesn't mean we need to stop talking about it, but maybe instead of hollering about the need for repotags it's time to collaborate in the other direction -- building a better way to track reopsitories into the RPM database itself.
Ray
Ray Van Dolson wrote:
It's unfortunate, but doesn't seem like it's going to change. I guess that doesn't mean we need to stop talking about it, but maybe instead of hollering about the need for repotags it's time to collaborate in the other direction -- building a better way to track reopsitories into the RPM database itself.
Yes, but it really needs to be tracked at the installed file level so that rpm and yum could refuse by default to overwrite any existing filename with a version from a different source unless it explicitly obsoletes the one to be replaced. That way the conflicts couldn't be accidental and if you want to replace someone else's file you'd have to say so.
On Thu, Dec 06, 2007 at 10:08:38AM -0800, Ray Van Dolson wrote:
On Thu, Dec 06, 2007 at 12:03:51PM -0600, Les Mikesell wrote:
Morten Torstensen wrote:
[snip away bible quotes]
This is getting way off topic, please consider what you post.
Having only one true repository whose name shall not be uttered in the package filenames doesn't remind you of anything?
No. What exactly are you getting at? :)
Seems like this issue is kinda moot at this point... and honestly, although maybe it would have been _nice_ for EPEL to use repotags, I think their thinking is that Fedora and Fedora Extras in the past doesn't use them; they consider themselves "upstream" in a way and are sticking to that same behavior. They also didn't feel that repotags were really a good solution to the problem.
Many discussions and arguments occurred, but in the end this is how it worked out. And if I recall, EPEL did finally agree to use repotags, but ATrpms had already removed all repotags from their packages so the driving reason to do it was at that point gone.
Oh, no, don't put the blame on ATrpms ;)
The repotag issue was just a frontend where the non-cooperation of EPEL with the rest of the world was demonstrated to beyond anyone's imagination. Only after several people that EPEL was trying to attract turned their backs and upon that some RH officials raised their heads to the EPEL "chairmen" where there some reevaluation about repotags.
So repotags was a small issue which failed on EPEL's non-cooperation. I don't see why more important issues would ever have a better faith, and I lost a lot of momentum in this fake discussion. The bottom point is that EPEL just wanted to enter the repo world of RHEL/CentOS and friends w/o caring about what existed there, and placing any compatibilty burden on others' shoulders.
It's unfortunate, but doesn't seem like it's going to change. I guess that doesn't mean we need to stop talking about it, but maybe instead of hollering about the need for repotags it's time to collaborate in the other direction -- building a better way to track reopsitories into the RPM database itself.
No *technical* solution will ever solve this. Even the best package manager in the world cooking coffee in its idle time will not solve packagers not talking to each other and creating conflicting and incompatible packages. And we've tried talking and coordinating, it's the EPEL side of the world that decides to play the Highlander theme again ("there can only be one").
So to answer the subject: No, EPEL is incompatible to every other repo that existed before EPEL came up. That was not the original promise of EPEL (I know as I was a steering member before I gave up on this insanity course), but it developed that way. </rant>
On Dec 6, 2007 2:24 PM, Axel Thimm Axel.Thimm@atrpms.net wrote:
So to answer the subject: No, EPEL is incompatible to every other repo that existed before EPEL came up. That was not the original promise of EPEL (I know as I was a steering member before I gave up on this insanity course), but it developed that way.
</rant>
Actually it would have been the case at some point as soon as it was looked at that they would use Fedora packaging standards versus some other set of standards.. The guidelines that you, DAG, etc conflict in various places and conflicted before EPEL was a gleam in its parents eye. It is also because you serve different audiences. I know that if I want bleeding edge packages that will pull in all sorts of new Perl/Pythons etc.. I have used ATrpms because you do what is needed to get XYZ-9 working. DAG might on the other hand may decide that XYZ-9 is not going to be supported in the same way because on RHEL-3 bringing in Python-3.00beta is just too much of a headache especially if its going to break everything else.
Mixing the two repositories in that case will cause unintended problems.. which at that point the repotags would be helpful in saying 'well don't mix them in this case' but wont have stopped the problem from occurring in the first place.
However at some point people quit thinking logically and instead started just throwing virtual dung at each other like we hadn't evolved much in the last million years. And after that everyone spent time trying to point out that the other side started throwing the dung first and if you didn't agree with that you had to be on the other side and oh here is some dung. Of course saying 'well let bygones be bygones' isn't going to happen until the other side publicly castrates itself as a sign of good faith.
I would say that the only thing that needs to top this off is some rumours that the other side is going to use bitkeeper for its source control, or ESR saying they thought that ZYZ was now his preferred repo and RMS saying that the other was the only true repository.
Stephen John Smoogen wrote:
I would say that the only thing that needs to top this off is some rumours that the other side is going to use bitkeeper for its source control, or ESR saying they thought that ZYZ was now his preferred repo and RMS saying that the other was the only true repository.
...or why Linux can't include zfs because it can't be restricted enough to call it free.
Les Mikesell wrote:
Stephen John Smoogen wrote:
I would say that the only thing that needs to top this off is some rumours that the other side is going to use bitkeeper for its source control, or ESR saying they thought that ZYZ was now his preferred repo and RMS saying that the other was the only true repository.
...or why Linux can't include zfs because it can't be restricted enough to call it free.
les,
drop this subject here, if you want to carry on talking about it - take it to epel or rpmforge lists.
On Thu, Dec 06, 2007 at 02:57:11PM -0700, Stephen John Smoogen wrote:
However at some point people quit thinking logically and instead started just throwing virtual dung at each other
Personally I think that oversimplifies the issue a lot. There was a plea for cooperation from one side and a strong Darwinistic move from the other one. Even EPEL key steering committee members confirm themselves that they want to have only EPEL around, even before EPEL existed - the EPEL archives can show you the infinite discussion threads on that.
I don't see any departure from logical thinking if one party decides to not cooperate and drop the burden on the others that the others just turn away.
Axel Thimm wrote:
No *technical* solution will ever solve this. Even the best package manager in the world cooking coffee in its idle time will not solve packagers not talking to each other and creating conflicting and incompatible packages. And we've tried talking and coordinating, it's the EPEL side of the world that decides to play the Highlander theme again ("there can only be one").
But that's not the problem that needs to be solved. We want/need incompatible versions of the same things to be available in different repos and for different reasons. What's missing is a mechanism to exclude conflicting groups when updating or to permit them to co-exist in the same machine by installing under different paths.
Axel Thimm wrote:
So repotags was a small issue which failed on EPEL's non-cooperation. I don't see why more important issues would ever have a better faith, and I lost a lot of momentum in this fake discussion. The bottom point is that EPEL just wanted to enter the repo world of RHEL/CentOS and friends w/o caring about what existed there, and placing any compatibilty burden on others' shoulders.
I thought that, originally, EPEL was supposed to be "Fedora Extras for RHEL"? If that's the case, compatibility would naturally be an issue, something that they need to add on top of the simple translation from Fedora to RHEL. I can definitely see why they would be reluctant to do that.
OTOH, yes, it would be so nice if all repos would be 100% compatible with each other. :-)
Florin Andrei wrote:
OTOH, yes, it would be so nice if all repos would be 100% compatible with each other. :-)
No it wouldn't because the reason you install something from a 3rd party repo may be precisely because its differences. Maybe it would be nice if anything incompatible had a different name - or maybe not. You can leave everyone else out of this discussion if you think about what should happen if you've installed a kernel from the centosplus repo and need its features (e.g. one of the added filesystems)to make your system work at all. Now, should some other repo's kernel automatically obsolete and replace that one just because it bumps the version number and appears in some other active repo first? Should you have to know a lot of obscure details and edit obscure files to keep this from happening?
On Fri, Dec 07, 2007 at 02:21:20PM -0600, Les Mikesell wrote:
Florin Andrei wrote:
OTOH, yes, it would be so nice if all repos would be 100% compatible with each other. :-)
No it wouldn't because the reason you install something from a 3rd party repo may be precisely because its differences.
But that doesn't mean that it is incompatible. If repo X ships a rather non-enabled version of a package foo and repo Y an enhanched one with more options turned on or whatever, if repo X and repo Y had a compatibility agreement them Y's foo would not wreck havoc on an X system and vice versa.
We're thinking of shipping several "different" packages in otherwise compatible subrepos, so there is a distinction between different and incompatible.
Bottom line once again: It's about people working or not together even in different repos. And I know that if there is a compatibility issue in say KB, Dag, Dries, ... or ATrpms that I can contact the other repo and fix a solution (heck most of us even share the same bugzilla instance). That's certainly not the case with EPEL.
Axel Thimm wrote:
On Fri, Dec 07, 2007 at 02:21:20PM -0600, Les Mikesell wrote:
Florin Andrei wrote:
OTOH, yes, it would be so nice if all repos would be 100% compatible with each other. :-)
No it wouldn't because the reason you install something from a 3rd party repo may be precisely because its differences.
But that doesn't mean that it is incompatible. If repo X ships a rather non-enabled version of a package foo and repo Y an enhanched one with more options turned on or whatever, if repo X and repo Y had a compatibility agreement them Y's foo would not wreck havoc on an X system and vice versa.
We're thinking of shipping several "different" packages in otherwise compatible subrepos, so there is a distinction between different and incompatible.
Bottom line once again: It's about people working or not together even in different repos. And I know that if there is a compatibility issue in say KB, Dag, Dries, ... or ATrpms that I can contact the other repo and fix a solution (heck most of us even share the same bugzilla instance). That's certainly not the case with EPEL.
I'd be happy to host the rest of this conversation in centos-devel@centos.org - which might actually have more people watching who play a role in these situations ?
On Friday 07 December 2007, Karanbir Singh wrote:
I'd be happy to host the rest of this conversation in centos-devel@centos.org - which might actually have more people watching who play a role in these situations ?
There is one point that belongs in the user CentOS list (and not on centos-devel) that is relevant to this discussion. And, Johnny, I know it isn't a CentOS issue; it is a CentOS user's issue, however, and this is the only post on this subject I plan to make.
If a CentOS user wants KDE-Redhat on CentOS, then that user will be using EPEL (KDE-Redhat now requires it).
The incompatibility between EPEL and, say, DAG, means you no longer can mix KDE-Redhat and DAG (which I have done on a few C4 boxes a while back). At some point, due to the EPEL requirement, yum update will quit working. If you happen to have used a DAG package that is incompatible at a low level with EPEL's package of the same program, you have work to do.
Noting repository incompatibilities is a user issue; arguing/debating the merits of the repos and trying to collaborate is, as you have correctly noted, a developer issue.
On Sat, Dec 08, 2007 at 08:15:07PM -0500, Lamar Owen wrote:
On Friday 07 December 2007, Karanbir Singh wrote:
I'd be happy to host the rest of this conversation in centos-devel@centos.org - which might actually have more people watching who play a role in these situations ?
There is one point that belongs in the user CentOS list (and not on centos-devel) that is relevant to this discussion. And, Johnny, I know it isn't a CentOS issue; it is a CentOS user's issue, however, and this is the only post on this subject I plan to make.
If a CentOS user wants KDE-Redhat on CentOS, then that user will be using EPEL (KDE-Redhat now requires it).
The incompatibility between EPEL and, say, DAG, means you no longer can mix KDE-Redhat and DAG (which I have done on a few C4 boxes a while back). At some point, due to the EPEL requirement, yum update will quit working. If you happen to have used a DAG package that is incompatible at a low level with EPEL's package of the same program, you have work to do.
In that case you should ask the kde-redhat developers (Rex and friends, and Rex is even on this list I think) to not create such a dependency. It is better to have some redundancy to allow the repo to be used with other repos than to bundle it with only one and outcast the other combinations.
Given that *probably* the needed parts are maintained by Rex himself in Fedora/EPEL anyway that would be not an issue anyway (noone will blame the other of incompatible/forked/stolen work - it's the same packager(s)).
Noting repository incompatibilities is a user issue; arguing/debating the merits of the repos and trying to collaborate is, as you have correctly noted, a developer issue.
Axel Thimm wrote:
OTOH, yes, it would be so nice if all repos would be 100% compatible with each other. :-)
No it wouldn't because the reason you install something from a 3rd party repo may be precisely because its differences.
But that doesn't mean that it is incompatible. If repo X ships a rather non-enabled version of a package foo and repo Y an enhanched one with more options turned on or whatever, if repo X and repo Y had a compatibility agreement them Y's foo would not wreck havoc on an X system and vice versa.
OK, but if your package manager can handle the incompatible case, it also won't surprise you when repo X updates their compatible but not fully functional version before repo Y does.
We're thinking of shipping several "different" packages in otherwise compatible subrepos, so there is a distinction between different and incompatible.
If the packages and all included files can be named differently, they could simply co-exist, but that doesn't always work.
Bottom line once again: It's about people working or not together even in different repos. And I know that if there is a compatibility issue in say KB, Dag, Dries, ... or ATrpms that I can contact the other repo and fix a solution (heck most of us even share the same bugzilla instance). That's certainly not the case with EPEL.
But it would be even better if we could live with the assumption that repos will have incompatibilities, whether accidental or intentional. Then it would become a choice of which to install and things wouldn't break when somewhere else updates first. Then you could focus on making your versions better instead of compatible - and the politics wouldn't matter.
On Fri, Dec 07, 2007 at 05:12:06PM -0600, Les Mikesell wrote:
But it would be even better if we could live with the assumption that repos will have incompatibilities, whether accidental or intentional. Then it would become a choice of which to install and things wouldn't break when somewhere else updates first. Then you could focus on making your versions better instead of compatible - and the politics wouldn't matter.
Sorry, that's not possible. Just to give an example: For some reason you favour repo A and make it trump over repo B. Both repos ship libfoo and repo B ships also appbaz needing libfoo with a couple more configure options turned on.
No smart package manager in the world will detect this breakage. One could strat thinking about stricter dependencies etc. but there will always be real-world scenarios like the above spoiling your master plan.
IMHO if the people don't cooperate the bits won't either. It is a rather lost cause to try to engineer around this problem.
Axel Thimm wrote:
On Fri, Dec 07, 2007 at 05:12:06PM -0600, Les Mikesell wrote:
But it would be even better if we could live with the assumption that repos will have incompatibilities, whether accidental or intentional. Then it would become a choice of which to install and things wouldn't break when somewhere else updates first. Then you could focus on making your versions better instead of compatible - and the politics wouldn't matter.
Sorry, that's not possible. Just to give an example: For some reason you favour repo A and make it trump over repo B. Both repos ship libfoo and repo B ships also appbaz needing libfoo with a couple more configure options turned on.
No smart package manager in the world will detect this breakage. One could strat thinking about stricter dependencies etc. but there will always be real-world scenarios like the above spoiling your master plan.
How much more information would rpm/yum need to store and consider in order to understand that they should never overwrite a package from one repository with one from a different repository without explicit instructions? Permitting explicit repository-specific dependencies would be nice too, although that could be worked around given the ability to control the initial repo for a package and an understanding that no other repo's version should replace it without permission even if it has the same name and a higher version number.
On Sun, Dec 09, 2007 at 01:15:08PM -0600, Les Mikesell wrote:
Axel Thimm wrote:
On Fri, Dec 07, 2007 at 05:12:06PM -0600, Les Mikesell wrote:
But it would be even better if we could live with the assumption that repos will have incompatibilities, whether accidental or intentional. Then it would become a choice of which to install and things wouldn't break when somewhere else updates first. Then you could focus on making your versions better instead of compatible - and the politics wouldn't matter.
Sorry, that's not possible. Just to give an example: For some reason you favour repo A and make it trump over repo B. Both repos ship libfoo and repo B ships also appbaz needing libfoo with a couple more configure options turned on.
No smart package manager in the world will detect this breakage. One could strat thinking about stricter dependencies etc. but there will always be real-world scenarios like the above spoiling your master plan.
How much more information would rpm/yum need to store and consider in order to understand that they should never overwrite a package from one repository with one from a different repository without explicit instructions?
Les, please read the example again. It assumes that rpm/yum already does so (and indeed with some plugins you can do that), but shows that you still end up with a broken system.
Permitting explicit repository-specific dependencies would be nice too, although that could be worked around given the ability to control the initial repo for a package and an understanding that no other repo's version should replace it without permission even if it has the same name and a higher version number.
I'll just repeat myself: If the packagers don't cooperate no technical solution will be able to really cover compatibilty problems. You'll paper over some of them and create a false feeling that you have mastered the compatibility problem and still wonder later why it doesn't work. I've seen dozen of such false bug reports which I call "partial/selective enabling of repos". Google the last term and you find many bad examples of such "solutions".
Am Sonntag, den 09.12.2007, 21:27 +0200 schrieb Axel Thimm:
... I'll just repeat myself: If the packagers don't cooperate no technical solution will be able to really cover compatibilty problems. You'll paper over some of them and create a false feeling that you have mastered the compatibility problem and still wonder later why it doesn't work. I've seen dozen of such false bug reports which I call "partial/selective enabling of repos". Google the last term and you find many bad examples of such "solutions".
IMHO the best solution would be if CentOS would ship its repo-files preconfigured for yum-priorities plugin and the priorities plugin for yum by default. This would prevent that 3rd party repos to override CentOS base packages.
On Sun, Dec 09, 2007 at 08:32:57PM +0100, Heiko Adams wrote:
Am Sonntag, den 09.12.2007, 21:27 +0200 schrieb Axel Thimm:
... I'll just repeat myself: If the packagers don't cooperate no technical solution will be able to really cover compatibilty problems. You'll paper over some of them and create a false feeling that you have mastered the compatibility problem and still wonder later why it doesn't work. I've seen dozen of such false bug reports which I call "partial/selective enabling of repos". Google the last term and you find many bad examples of such "solutions".
IMHO the best solution would be if CentOS would ship its repo-files preconfigured for yum-priorities plugin and the priorities plugin for yum by default. This would prevent that 3rd party repos to override CentOS base packages.
But what does that have to do with 3rd party repos A and B supporting CentOS but being incompatible towards each other? This is not about 3rd party repos replacing a vendor package, which is a different policy issue altogether (and which is best solved by different offerings on the server side anyway).
Am Sonntag, den 09.12.2007, 21:39 +0200 schrieb Axel Thimm:
... But what does that have to do with 3rd party repos A and B supporting CentOS but being incompatible towards each other? This is not about 3rd party repos replacing a vendor package, which is a different policy issue altogether (and which is best solved by different offerings on the server side anyway).
Clarification: If the priorities plugin for yum would be installed by default or as an dependency of the 3rd party repo-release-packages it would be easier to tell the users to use this plugin.
In fact it's nearly impossible for 3rd party repo maintainers to keep there repo compatible to more than one other 3rd party repo. So it's the users job to prevent their installed 3rd party repo to replace other 3rd party repo packages.
On Sun, Dec 09, 2007 at 08:55:08PM +0100, Heiko Adams wrote:
Am Sonntag, den 09.12.2007, 21:39 +0200 schrieb Axel Thimm:
... But what does that have to do with 3rd party repos A and B supporting CentOS but being incompatible towards each other? This is not about 3rd party repos replacing a vendor package, which is a different policy issue altogether (and which is best solved by different offerings on the server side anyway).
Clarification: If the priorities plugin for yum would be installed by default or as an dependency of the 3rd party repo-release-packages it would be easier to tell the users to use this plugin.
Priorities are evil and endorsing them is the wrong path. See my replyies to Les.
In fact it's nearly impossible for 3rd party repo maintainers to keep there repo compatible to more than one other 3rd party repo. So it's the users job to prevent their installed 3rd party repo to replace other 3rd party repo packages.
Priorities and friends are not the answer, they are the second stage of complicating a problem.
On Sun, 2007-12-09 at 20:32 +0100, Heiko Adams wrote:
Am Sonntag, den 09.12.2007, 21:27 +0200 schrieb Axel Thimm:
... I'll just repeat myself: If the packagers don't cooperate no technical solution will be able to really cover compatibilty problems. You'll paper over some of them and create a false feeling that you have mastered the compatibility problem and still wonder later why it doesn't work. I've seen dozen of such false bug reports which I call "partial/selective enabling of repos". Google the last term and you find many bad examples of such "solutions".
IMHO the best solution would be if CentOS would ship its repo-files preconfigured for yum-priorities plugin and the priorities plugin for yum by default. This would prevent that 3rd party repos to override CentOS base packages.
---- which of course flies in the face of their commitment to staying true to upstream.
Ultimately, the user has to take responsibility for their own boxen.
Craig
Axel Thimm wrote:
Sorry, that's not possible. Just to give an example: For some reason you favour repo A and make it trump over repo B. Both repos ship libfoo and repo B ships also appbaz needing libfoo with a couple more configure options turned on.
No smart package manager in the world will detect this breakage. One could strat thinking about stricter dependencies etc. but there will always be real-world scenarios like the above spoiling your master plan.
How much more information would rpm/yum need to store and consider in order to understand that they should never overwrite a package from one repository with one from a different repository without explicit instructions?
Les, please read the example again. It assumes that rpm/yum already does so (and indeed with some plugins you can do that), but shows that you still end up with a broken system.
I still don't understand. If I had the ablility to specify which repo to use for libfoo and either the enhanced libfoo is backwards compatible or I can specify that all things depending on libfoo come from repo B, then subsequently the system knows enough not to overwrite repo B's packages with potentially different packages from some other repo, what will break?
I'll just repeat myself: If the packagers don't cooperate no technical solution will be able to really cover compatibilty problems. You'll paper over some of them and create a false feeling that you have mastered the compatibility problem and still wonder later why it doesn't work. I've seen dozen of such false bug reports which I call "partial/selective enabling of repos". Google the last term and you find many bad examples of such "solutions".
You'll find examples of where things in a single repository are incompatible with each other for certain periods of time so expecting perfection is obviously impossible. A technical means to control what you load won't stop you from doing something wrong but it would permit you do it right and keep it that way across updates.
On Sun, Dec 09, 2007 at 02:09:36PM -0600, Les Mikesell wrote:
Axel Thimm wrote:
Sorry, that's not possible. Just to give an example: For some reason you favour repo A and make it trump over repo B. Both repos ship libfoo and repo B ships also appbaz needing libfoo with a couple more configure options turned on.
No smart package manager in the world will detect this breakage. One could strat thinking about stricter dependencies etc. but there will always be real-world scenarios like the above spoiling your master plan.
How much more information would rpm/yum need to store and consider in order to understand that they should never overwrite a package from one repository with one from a different repository without explicit instructions?
Les, please read the example again. It assumes that rpm/yum already does so (and indeed with some plugins you can do that), but shows that you still end up with a broken system.
I still don't understand. If I had the ablility to specify which repo to use for libfoo and either the enhanced libfoo is backwards compatible or I can specify that all things depending on libfoo come from repo B, then subsequently the system knows enough not to overwrite repo B's packages with potentially different packages from some other repo, what will break?
You now input information that you probably only get after your system has been broken. How would you (or and other end-user) know in advance that one would need to special-treat libfoo? The typical user wouldn't even know what libs are needed for the app he/she wants to install.
And let's make the example insoluble: Now consider repo A shipping appbar which needs different build options than repo B's appbaz. Now the only thing that could save the day would be repo A and B talking.
I'll just repeat myself: If the packagers don't cooperate no technical solution will be able to really cover compatibilty problems. You'll paper over some of them and create a false feeling that you have mastered the compatibility problem and still wonder later why it doesn't work. I've seen dozen of such false bug reports which I call "partial/selective enabling of repos". Google the last term and you find many bad examples of such "solutions".
You'll find examples of where things in a single repository are incompatible with each other for certain periods of time
Which is a very bad repo design - that's why the idioms from Debian and Madriva concerning forward/backward compatibility libs are a must and not a nice-to-have option.
so expecting perfection is obviously impossible. A technical means to control what you load won't stop you from doing something wrong but it would permit you do it right and keep it that way across updates.
Perfection? No one is asking for that, but broken depsolver settings from priorities/weighing/name-it-as-you-like have cost me too much support time. It creates a per-user different invalid bug scenario which the repo managers have to untangle only to find out that appbaz was forced to work against another repo's libfoo due to per-user preferences.
Yes, per-user bugs are hideous and by design a bug in itself.
On Dec 6, 2007 11:03 AM, Les Mikesell lesmikesell@gmail.com wrote:
Morten Torstensen wrote:
[snip away bible quotes]
This is getting way off topic, please consider what you post.
Having only one true repository whose name shall not be uttered in the package filenames doesn't remind you of anything?
Most of the bickering and infighting and keeping grudges about things many years reminds me mostly of the Reformation. Protestants killing Catholics, Catholics killing Protestants, Protestants killing Protestants, Catholics killing Catholics, Everyone killing Muslims, Jews, and anyone who couldnt agree that 212 angels danced on the head of a pin. The language of the arguments is about the same.. just thankfully a lack of physical violence (just lots of verbal violence by various followers and sub-followers).
On Thu, 6 Dec 2007, Stephen John Smoogen wrote:
Most of the bickering and infighting and keeping grudges about things many years reminds me mostly of the Reformation. Protestants killing Catholics, Catholics killing Protestants, Protestants killing Protestants, Catholics killing Catholics, Everyone killing Muslims, Jews, and anyone who couldnt agree that 212 angels danced on the head of a pin. The language of the arguments is about the same.. just thankfully a lack of physical violence (just lots of verbal violence by various followers and sub-followers).
Tom Lehrer sang it best:
http://www.youtube.com/watch?v=aIlJ8ZCs4jY
Please don't post HTML messages. Firefox renders your messages in about 4 points. Quite unreadable.
Please, this is not meant to start a war.
Thanks.
ok...
How about wxGTK. rpmforge is distributing 2.6.3 while epel is distributing 2.8.? rpmforge's vlc uses wxGTK or there are interlinked dependencies...
So when I "yum -y update", the update fails. Currently there are no pending updates so this is not a big deal... until there are pending updates.
As an end user, I just want to be able to update my system.
If to accomplish that, I have to disable epel and only use it when I'm looking for something, then that's what I'll have to do.
R P Herrold wrote:
On Thu, 6 Dec 2007, Rex Dieter wrote: Rex Dieter replied:
If you can identify particular cases where collaboration, as outlined in the above policy draft, was not followed, I will personally break out a can of whoop-ass, and work to fix things.
on 12/6/2007 3:22 PM Milton Calnek spake the following:
ok...
How about wxGTK. rpmforge is distributing 2.6.3 while epel is distributing 2.8.? rpmforge's vlc uses wxGTK or there are interlinked dependencies...
So when I "yum -y update", the update fails. Currently there are no pending updates so this is not a big deal... until there are pending updates.
As an end user, I just want to be able to update my system.
If to accomplish that, I have to disable epel and only use it when I'm looking for something, then that's what I'll have to do.
I do that now with the ATRPms repo. It can conflict with rpmforge a lot, but the two were not meant to be used together. One works for more backward compatibility, while the other works for addons that might change the function of the system. CentOS's own "plus" repo does the same. It isn't good or bad in itself, you just need to make choices on what you want to accomplish.
"When you are up to your elbows in alligators, it is hard to remember that your original objective was to drain the swamp!"
Milton Calnek wrote:
ok...
How about wxGTK. rpmforge is distributing 2.6.3 while epel is distributing 2.8.? rpmforge's vlc uses wxGTK or there are interlinked dependencies...
perhaps you didnt read the thread before posting, but I politely asked people to take it elsewhere.
On Dec 6, 2007 4:53 PM, Karanbir Singh mail-lists@karan.org wrote:
perhaps you didnt read the thread before posting, but I politely asked people to take it elsewhere.
Karanbir Singh : http://www.karan.org/ : 2522219@icq
If people ever listen to others, this thread would not have gone wild. In the 3rd e-mail of this thread, I specifically asked:
" In any event, let's not start yet another EPEL discussion here. :-) " (Tue Dec 4 19:51:41 UTC 2007)
http://lists.centos.org/pipermail/centos/2007-December/090427.html
Akemi
Rex Dieter wrote:
R P Herrold wrote:
On Wed, 5 Dec 2007, Rex Dieter wrote:
Huh? In fact, work is underway to codify the opposite: http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration
James 2:14-26
If you can identify particular cases where collaboration, as outlined in the above policy draft, was not followed, I will personally break out a can of whoop-ass, and work to fix things.
Remember too, collaboration is a two-way street.
How does a user identify packages that have come from this repository in order to fix or control any incompatibilities?
Rex Dieter wrote:
Les Mikesell wrote:
How does a user identify packages that have come from this repository in order to fix or control any incompatibilities?
rpm -qi <name_of_package> Look for "Vendor" and/or "Packager" tag.
Is there some reason to expect a vendor/packager to always (and only) be tied to one specific repository? And is there a way to get my whole list of packages from this repository easily, like an 'rpm -qa |grep .plus would identify what I have from the centosplus repo?
Les Mikesell wrote:
Rex Dieter wrote:
Les Mikesell wrote:
How does a user identify packages that have come from this repository in order to fix or control any incompatibilities?
rpm -qi <name_of_package> Look for "Vendor" and/or "Packager" tag.
Is there some reason to expect a vendor/packager to always (and only) be tied to one specific repository?
For the most part, yes, I'd argue the vendor/packager combo should come close to being able to uniquely identify a package's origins.
And is there a way to get my whole
list of packages from this repository easily, like an 'rpm -qa |grep .plus would identify what I have from the centosplus repo?
This is a problem space that sure could use some love and attention, with better solutions and tools. No doubt about it. And before anyone suggests it, repotags are not the end-all-be-all solution here, imo. We can/should be able to do (much) better.
-- Rex
Rex Dieter wrote:
How does a user identify packages that have come from this repository in order to fix or control any incompatibilities?
rpm -qi <name_of_package> Look for "Vendor" and/or "Packager" tag.
Is there some reason to expect a vendor/packager to always (and only) be tied to one specific repository?
For the most part, yes, I'd argue the vendor/packager combo should come close to being able to uniquely identify a package's origins.
In a system that might want to call itself a community, I don't see why a particular package couldn't be served from more than one repository. Is there some rule about that?
And is there a way to get my whole
list of packages from this repository easily, like an 'rpm -qa |grep .plus would identify what I have from the centosplus repo?
This is a problem space that sure could use some love and attention, with better solutions and tools. No doubt about it. And before anyone suggests it, repotags are not the end-all-be-all solution here, imo. We can/should be able to do (much) better.
There are lots of things that RPM packaging doesn't handle very well and won't for the foreseeable future. Meanwhile we need to do things with conventions and workarounds since that's all we have. And there's nothing wrong with making things visible with filename conventions.
Rex Dieter wrote:
I don't see why a particular package couldn't be served from more than one repository. Is there some rule about that?
Nope. As a matter of fact, this sort of thing is likely when mixing repos, and is why a commitment to collaboration is essential.
The point is that as an end user, I want a sensible way to deal with multiple repositories that _don't_ collaborate. After all, if everyone agreed on policies we wouldn't need any third party repositories at all. The reason I want something from somewhere else may be precisely because they do things differently. In fact, I'd love to see an optional repository that could be used from Centos whose policy was basically that packages had been released in fedora for at least a month with no system-crashing bugs reported against it or dependencies.
On Dec 6, 2007 12:11 PM, Les Mikesell lesmikesell@gmail.com wrote:
Rex Dieter wrote:
I don't see why a particular package couldn't be served from more than one repository. Is there some rule about that?
Nope. As a matter of fact, this sort of thing is likely when mixing repos, and is why a commitment to collaboration is essential.
The point is that as an end user, I want a sensible way to deal with multiple repositories that _don't_ collaborate. After all, if everyone agreed on policies we wouldn't need any third party repositories at all.
Ok the problem field is that you have N different repositories, using M different guidelines, using O different compile flags, and P different filesystem layouts. The best you could possibly do is not have packages at all but keep each package in a dmg file and let the ld fight it out over who gets executed today... but that would seem to be a different OS.
The reason I want something from somewhere else may be precisely because they do things differently. In fact, I'd love to see an optional repository that could be used from Centos whose policy was basically that packages had been released in fedora for at least a month with no system-crashing bugs reported against it or dependencies.
-- Les Mikesell lesmikesell@gmail.com
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Stephen John Smoogen wrote:
The point is that as an end user, I want a sensible way to deal with multiple repositories that _don't_ collaborate. After all, if everyone agreed on policies we wouldn't need any third party repositories at all.
Ok the problem field is that you have N different repositories, using M different guidelines, using O different compile flags, and P different filesystem layouts.
The constraint is simply that you do not replace any file/library with one that is incompatible. The Sun people like to claim that you can run anything that ever ran on Solaris on subsequent versions so the problem space isn't as impossible as you make it seem - it is more a matter of respecting interfaces and backwards compatibility. But my point is that I don't want to be forced to use a repository that always follows this constraint. Sometimes compatibility is what you want, sometimes you want something different, and you need to be able to manage both.
The best you could possibly do is not have packages at all but keep each package in a dmg file and let the ld fight it out over who gets executed today... but that would seem to be a different OS.
Yes, that would make Linux as difficult to maintain as a Mac.
On Dec 6, 2007 12:51 PM, Les Mikesell lesmikesell@gmail.com wrote:
Stephen John Smoogen wrote:
The point is that as an end user, I want a sensible way to deal with multiple repositories that _don't_ collaborate. After all, if everyone agreed on policies we wouldn't need any third party repositories at all.
Ok the problem field is that you have N different repositories, using M different guidelines, using O different compile flags, and P different filesystem layouts.
The constraint is simply that you do not replace any file/library with one that is incompatible.
And how do you know it isnt compatible? Keeping ABI's the same is extremely hard work and basically would mean that a repository rarely puts up new stuff but only backports items from upstream. Thats a lot of work for something they don't get paid for. And even if the ABI is the same, it doesnt mean that you have different actions occur because one had a compiler with XYZ flag in it and the other had XZY.
The Sun people like to claim that you can run anything that ever ran on Solaris on subsequent versions so the problem space isn't as impossible as you make it seem - it is more a matter of respecting interfaces and backwards compatibility.
And that was a load of bull from Solaris. You could run most Sun things from Solaris 2.x to 2.x1 but the list of things that didn't run as expected was always pretty long. And to do that they had to basically strip down the OS to extremely limited functionality. That was why it was such a 'radical' change when they started shipping GNU tools in the OS because it had been requested for years but the amount of churn was too high for them to want to deal with.
But my point is that I don't want to be forced to use a repository that always follows this constraint. Sometimes compatibility is what you want, sometimes you want something different, and you need to be able to manage both.
But are you willing to pay for that? Because its not an easy problem to solve that people can throw more computers at and get it working. It usually requires a lot of meat-ware time with people working out meat-ware politics and issues.
The best you could possibly do is not have packages at all but keep each package in a dmg file and let the ld fight it out over who gets executed today... but that would seem to be a different OS.
Yes, that would make Linux as difficult to maintain as a Mac.
Maintainability is usually on the opposite side of choices.
Stephen John Smoogen wrote:
On Dec 6, 2007 12:51 PM, Les Mikesell lesmikesell@gmail.com wrote:
Stephen John Smoogen wrote:
The point is that as an end user, I want a sensible way to deal with multiple repositories that _don't_ collaborate. After all, if everyone agreed on policies we wouldn't need any third party repositories at all.
Ok the problem field is that you have N different repositories, using M different guidelines, using O different compile flags, and P different filesystem layouts.
The constraint is simply that you do not replace any file/library with one that is incompatible.
And how do you know it isnt compatible? Keeping ABI's the same is extremely hard work and basically would mean that a repository rarely puts up new stuff but only backports items from upstream. Thats a lot of work for something they don't get paid for. And even if the ABI is the same, it doesnt mean that you have different actions occur because one had a compiler with XYZ flag in it and the other had XZY.
The Sun people like to claim that you can run anything that ever ran on Solaris on subsequent versions so the problem space isn't as impossible as you make it seem - it is more a matter of respecting interfaces and backwards compatibility.
And that was a load of bull from Solaris. You could run most Sun things from Solaris 2.x to 2.x1 but the list of things that didn't run as expected was always pretty long. And to do that they had to basically strip down the OS to extremely limited functionality. That was why it was such a 'radical' change when they started shipping GNU tools in the OS because it had been requested for years but the amount of churn was too high for them to want to deal with.
But my point is that I don't want to be forced to use a repository that always follows this constraint. Sometimes compatibility is what you want, sometimes you want something different, and you need to be able to manage both.
But are you willing to pay for that? Because its not an easy problem to solve that people can throw more computers at and get it working. It usually requires a lot of meat-ware time with people working out meat-ware politics and issues.
The best you could possibly do is not have packages at all but keep each package in a dmg file and let the ld fight it out over who gets executed today... but that would seem to be a different OS.
Yes, that would make Linux as difficult to maintain as a Mac.
Maintainability is usually on the opposite side of choices.
guys, while somewhat relevant - this list is really not the place for this conversation. As has happened before its going to go round in circles with lots of noise - but no action.
On Thu, 6 Dec 2007, Rex Dieter wrote:
Les Mikesell wrote:
Rex Dieter wrote:
Les Mikesell wrote:
And is there a way to get my whole
list of packages from this repository easily, like an 'rpm -qa |grep .plus would identify what I have from the centosplus repo?
This is a problem space that sure could use some love and attention, with better solutions and tools. No doubt about it. And before anyone suggests it, repotags are not the end-all-be-all solution here, imo. We can/should be able to do (much) better.
Targetted for Fedora Core 9 ?
Nothing can replace the simplicity and ease of a repotag, which is a solution that works today on EL2, EL3, EL4 and EL5. Any other solution discussed over the last year does not exist and is nobody working on.
Despite this, the outcome on the LinuxTag meeting with Fedora/EPEL was that there was no good reason not to use repotags since they make the package name (= the part that the depsolver compares and uses) unique.
Feel free to come up with a solution, Rex. I no longer believe you will.
I have been looking for other reasons why Fedora/EPEL does not want to do it and have concluded that they directly benefit from the confusion about the origin of a package: people that cannot easily identify that a package comes from EPEL are less inclined to blame EPEL or remove the package.
So give a user a repotagged package and a non-repotagged package, the use may choose the non-repotagged one. EPEL wins.
Dag Wieers wrote:
On Thu, 6 Dec 2007, Rex Dieter wrote:
This is a problem space that sure could use some love and attention, with better solutions and tools. No doubt about it. And before anyone suggests it, repotags are not the end-all-be-all solution here, imo. We can/should be able to do (much) better.
...
Feel free to come up with a solution, Rex. I no longer believe you will.
This should/will be driven by those who feel passionate about it, and care enough to do something constructive. That someone is not *me* specifically.
-- Rex
On Fri, 7 Dec 2007, Rex Dieter wrote:
Dag Wieers wrote:
On Thu, 6 Dec 2007, Rex Dieter wrote:
This is a problem space that sure could use some love and attention, with better solutions and tools. No doubt about it. And before anyone suggests it, repotags are not the end-all-be-all solution here, imo. We can/should be able to do (much) better.
...
Feel free to come up with a solution, Rex. I no longer believe you will.
This should/will be driven by those who feel passionate about it, and care enough to do something constructive. That someone is not *me* specifically.
Sorry, that obviously was wrong, I meant Fedora/EPEL, not you specifically.
Apparently, people feeling passionate against repotags are not passionate about a solution altogether. You can insinuate that I am not constructive, but we have a solution that worked for the past 5 years, which is denied without real argumentation or alternative that is practical for EL2 upto EL5.
Dag Wieers wrote:
This is a problem space that sure could use some love and attention, with better solutions and tools. No doubt about it. And before anyone suggests it, repotags are not the end-all-be-all solution here, imo. We can/should be able to do (much) better.
...
Feel free to come up with a solution, Rex. I no longer believe you will.
This should/will be driven by those who feel passionate about it, and care enough to do something constructive. That someone is not *me* specifically.
Sorry, that obviously was wrong, I meant Fedora/EPEL, not you specifically.
Apparently, people feeling passionate against repotags are not passionate about a solution altogether. You can insinuate that I am not constructive, but we have a solution that worked for the past 5 years, which is denied without real argumentation or alternative that is practical for EL2 upto EL5.
I think this is really a tool issue, unless repotags are already enough to solve the problem that a newer package from any repo implicitly obsoletes existing ones of the same name. What we need is an update mechanism that permits groups of files to be replaced with incompatible versions from a different repo if explicitly told to do that, but subsequently (and always by default) will not update/replace any package with a version from a different repository.
But I thought someone mentioned earlier that conflicts happen if you enable both dag and atrpms, so repotags must not be enough even though they might help to diagnose the problem.
Hi Dag,
Dag Wieers wrote:
Targetted for Fedora Core 9 ?
Nothing can replace the simplicity and ease of a repotag, which is a solution that works today on EL2, EL3, EL4 and EL5. Any other solution discussed over the last year does not exist and is nobody working on.
I have repeatedly asked people to take this conversation away from this list. Is there really any point you are trying to make by carrying on ?
its not that hard to just post a follow up on another list, both you and rex are on the epel and the rpmforge lists. how about pick one and post the follow up's there ?
On Fri, 7 Dec 2007, Karanbir Singh wrote:
Dag Wieers wrote:
Targetted for Fedora Core 9 ?
Nothing can replace the simplicity and ease of a repotag, which is a solution that works today on EL2, EL3, EL4 and EL5. Any other solution discussed over the last year does not exist and is nobody working on.
I have repeatedly asked people to take this conversation away from this list. Is there really any point you are trying to make by carrying on ?
its not that hard to just post a follow up on another list, both you and rex are on the epel and the rpmforge lists. how about pick one and post the follow up's there ?
Did you consider that I read my mails chronologically and replied before I got to your post ?
Besides I did not start this thread, and many others have replied after your post as well. But if you had to pick on my to make an example or as a political statement, I don't mind being the stooge (just tell me in advance).
Dag Wieers wrote:
Besides I did not start this thread, and many others have replied after your post as well. But if you had to pick on my to make an example or as a political statement, I don't mind being the stooge (just tell me in advance).
i guess you havent read the full thread yet.
Karanbir Singh wrote:
I have repeatedly asked people to take this conversation away from this list. Is there really any point you are trying to make by carrying on ?
its not that hard to just post a follow up on another list, both you and rex are on the epel and the rpmforge lists. how about pick one and post the follow up's there ?
There is a distribution-related issue here whether you care to acknowledge it or not - and the solution isn't going to be to wait until the whole world decides on only one version of everything. Incompatible repositories should be allowed/encouraged to exist and we need a way to deal with them reasonably.
But on a more personal note you should take it as a tribute to to the base distro packaging that you've just rolled out a massive update and the chatter on the list is mostly rants about unrelated trivia.
Les Mikesell wrote:
Karanbir Singh wrote:
I have repeatedly asked people to take this conversation away from this list. Is there really any point you are trying to make by carrying on ?
its not that hard to just post a follow up on another list, both you and rex are on the epel and the rpmforge lists. how about pick one and post the follow up's there ?
There is a distribution-related issue here whether you care to acknowledge it or not - and the solution isn't going to be to wait until the whole world decides on only one version of everything. Incompatible repositories should be allowed/encouraged to exist and we need a way to deal with them reasonably.
THIS IS NOT A CENTOS ISSUE ... IT NEVER WILL BE A CENTOS ISSUE
When people use RHEL, they are not even allowed to use 3rd party repos without making their service contract void if it causes any problems at all.
We are a clone ... therefore we strive emulate the original.
Third party repo integration is NOT A CENTOS issue.
Anything that is not in the upstream distro (or in CentOSPlus or CentOSExtras repos or another repo we add) IS NOT A CENTOS issue.
If people want to use smart package manager or apt-rpm or synaptic instead of yum ... THAT IS NOT A CENTOS ISSUE.
If people think yum sucks, or rpm sucks, or gnome 2.16 sucks, or any other thing provided by upstream sucks ... IT IS NOT A CENTOS ISSUE
We can not change the files that are included upstream, nor can we make people build repos that are compatible with each other.
WHY OH WHY OH WHY
Johnny Hughes wrote:
I have repeatedly asked people to take this conversation away from this list. Is there really any point you are trying to make by carrying on ?
its not that hard to just post a follow up on another list, both you and rex are on the epel and the rpmforge lists. how about pick one and post the follow up's there ?
There is a distribution-related issue here whether you care to acknowledge it or not - and the solution isn't going to be to wait until the whole world decides on only one version of everything. Incompatible repositories should be allowed/encouraged to exist and we need a way to deal with them reasonably.
THIS IS NOT A CENTOS ISSUE ... IT NEVER WILL BE A CENTOS ISSUE
[...]
Anything that is not in the upstream distro (or in CentOSPlus or CentOSExtras repos or another repo we add) IS NOT A CENTOS issue.
[...]
WHY OH WHY OH WHY
Did you miss my point that _exactly_ the same problem occurs when you load (and need) a kernel from centosplus and it is implicitly obsoleted if a newer version number appears on a kernel that won't work for you in a different repository that you have enabled. This is a centos tool issue. I know there is an ugly workaround if you know a lot of details and want to defeat way the tools are supposed to be handling things for you automatically, but it is not at all elegant like the rest of Centos.
Solve the <any newer version from any repo obsoletes any potentially different package from a different repo> in a general way and then not only does the impossible task of making the world code-compatible go away, but then we can easily take advantage of different/better packages in additional repos like centosplus.
On Sat, 8 Dec 2007, Johnny Hughes wrote:
Les Mikesell wrote:
There is a distribution-related issue here whether you care to acknowledge it or not - and the solution isn't going to be to wait until the whole world decides on only one version of everything. Incompatible repositories should be allowed/encouraged to exist and we need a way to deal with them reasonably.
THIS IS NOT A CENTOS ISSUE ... IT NEVER WILL BE A CENTOS ISSUE
When people use RHEL, they are not even allowed to use 3rd party repos without making their service contract void if it causes any problems at all.
Johnny, that is incorrect. Red Hat customers don't void their service contract for using 3rd party repositories or 3rd party packages.
A lot of Red Hat consultants have been using RPMforge packages at customer sites to fix problems or offer solutions and they were not voiding their service contract.
What kind of operating system would not allow alien software anyway ?
And even when you are loading 3rd party kernel modules, Red Hat will still have to support you for issues that are unrelated to this particular kernel module. Otherwise one could not use ClearCase, GPFS, some of your hardware without loosing support from Red Hat.
I understand CentOS's position to simplify user-related issues, but the use of 3rd party software on top of CentOS is as much a CentOS user problem as it is a 3rd party software problem in most cases. Users should be able to discuss problems, work-arounds and solutions on a CentOS mailinglist (even when it is not something that can be fixed within CentOS itself).
Am Sonntag, den 09.12.2007, 18:04 +0100 schrieb Dag Wieers:
... I understand CentOS's position to simplify user-related issues, but the use of 3rd party software on top of CentOS is as much a CentOS user problem as it is a 3rd party software problem in most cases. Users should be able to discuss problems, work-arounds and solutions on a CentOS mailinglist (even when it is not something that can be fixed within CentOS itself).
I fully agree to your position but IMHO mailing lists for the specific repositorys would be a better place for those problems. Maybe CentOS could provide one or more lists for those repository related problems.
On Dec 4, 2007 11:12 AM, Florin Andrei florin@andrei.myip.org wrote:
Following Fabian's blog post re: RPMForge being rebuilt for EL5, I've a question:
Are there any compatibility problems between RPMForge and EPEL? In other words, if I enabled EPEL previously, will I be able to enable RPMForge as well without running into trouble?
Speaking from a technical standpoint, the biggest issue with mixing any different repos is that they use different packaging guidelines. The hyperbole case: package repo A uses SuSE standards, repo B were to use Fedora 1.x standards, repo C were to use current Fedora standards, and repo D were to use Mandrake standards.. you would end up with either file conflicts or worse yet lack of conflicts but hidden requirements (script from A expects files to be in /opt/blah/bin for some reason but you got that package from E because it was newer and it places things in /srv/snozzberry/bin instead.
The more common case I have found has been odd dependency chains from one side or another because of unclear guidelines. In most production environments, I tend to choose one repository and then work with that one only to get the job done. For some things it was ATrpms, others DAG, and other EPEL. If the item I needed was in one but not the other.. getting it into the one repository I was working with was easier than trying to figure out how to find any unknown unknowns in hidden conflicts.
As DAG has said several times in mailling lists.. the proper thing to do is not use a repository directly anyway. You should have an internal mirror of the main repo, and then several sub-repo's of just the packages you want your systems to have. You should have a testing routine where you take new packages test that they work with your environment and then push them out from the sub-repos. He has written several tools to make this possible..
Florin Andrei wrote:
Following Fabian's blog post re: RPMForge being rebuilt for EL5, I've a question:
Are there any compatibility problems between RPMForge and EPEL? In other words, if I enabled EPEL previously, will I be able to enable RPMForge as well without running into trouble?
The real, no bullcrap, and bottom line answer to this question is:
NO!!!!!!!!!!!!!!!
ATRPMS, RPMForge, and EPEL contain many conficts if all are used together.
You can mitigate this by using the priorities plugin in yum ... but eventually you will also have to use "exclude=" and maybe even "includepkgs=" options. See "man yum.conf" for details.
No amount of posting or ranting / complaining on the CentOS mailing list will solve this problem.
ATRPMS, RPMForge, and EPEL each have mailing lists and each have packaging guidelines and community leaders, etc. Those mailing lists are the place where these issues MIGHT be solved ... not here.
The CentOS Project has no input into what ANY of these repos do, so complaining, whining, bitching, moaning, ranting, screaming, gnashing of teeth, or any other thing ... when done on this list ... will have no impact on the situation. SO, please take it to the appropriate place.
As to what my personal option is about this situation .. please see this thread (on the appropriate mailing list):
http://www.redhat.com/archives/epel-devel-list/2007-April/msg00129.html
Thanks, Johnny Hughes
Florin Andrei wrote:
Following Fabian's blog post re: RPMForge being rebuilt for EL5, I've a question:
Are there any compatibility problems between RPMForge and EPEL? In other words, if I enabled EPEL previously, will I be able to enable RPMForge as well without running into trouble?
This thread is now moderated off.
-
Akemi Yagi -
Axel Thimm -
Bob Taylor -
Craig White -
Dag Wieers -
Florin Andrei -
Heiko Adams -
Jim Perrin -
Johnny Hughes -
Karanbir Singh -
Lamar Owen -
Les Mikesell -
Milton Calnek -
Morten Torstensen -
Paul Heinlein -
R P Herrold -
Ray Van Dolson -
Rex Dieter -
Scott Silva -
Stephen John Smoogen