hi all,
I received a message about EPEL repository, I would like to know if this repo is long term support too.
thanks;
Jc júnior
On Fri, 27 Jul 2007, JC Júnior wrote:
I received a message about EPEL repository, I would like to know if this repo is long term support too.
Let me add that an effort to make sure EPEL is compatible with RPMforge failed as EPEL wants to become the only repository for RHEL and there is no interest to consider current RPMforge users.
EPEL refused the repotag, so one cannot easily identify where a package comes from and mixing repositories becomes harder. Since compatibility is a 2 way interaction and EPEL shows no interest, it is certain that mixing EPEL with other repositories may break something.
Also EPEL's Fedora legacy makes EPEL closer to Fedora's Extras packages than they are with RPMforge's packages, which can lead to problems with eg. nagios-plugins or clamav packages.
I already foresee a lot of frustration caused by bug-reports that make it not clear that packages come from EPEL (much like in the Fedora era where Fedora Extras packages caused problems with RPMforge that were hard to identify or fix).
Also, EPEL packages only exist for RHEL4 and RHEL5, resp 340 and 600 projects while RPMforge builds for RHEL2, RHEL3, RHEL4 and RHEL5, about 3400 projects. We however do not provide any PPC packages.
As always, be careful what you enable and cherry pick rather than enable fully.
PS Within a corporate environment, look at the mrepo tool for managing repositories and cherry picking packages for deploying and managing systems. Do not enable repositories company wide !
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
Dumb question.
Can't we identify the source of the package by looking at the signature.
On 7/28/07, Dag Wieers dag@wieers.com wrote:
On Fri, 27 Jul 2007, JC Júnior wrote:
I received a message about EPEL repository, I would like to know if this
repo
is long term support too.
Let me add that an effort to make sure EPEL is compatible with RPMforge failed as EPEL wants to become the only repository for RHEL and there is no interest to consider current RPMforge users.
EPEL refused the repotag, so one cannot easily identify where a package comes from and mixing repositories becomes harder. Since compatibility is a 2 way interaction and EPEL shows no interest, it is certain that mixing EPEL with other repositories may break something.
Also EPEL's Fedora legacy makes EPEL closer to Fedora's Extras packages than they are with RPMforge's packages, which can lead to problems with eg. nagios-plugins or clamav packages.
I already foresee a lot of frustration caused by bug-reports that make it not clear that packages come from EPEL (much like in the Fedora era where Fedora Extras packages caused problems with RPMforge that were hard to identify or fix).
Also, EPEL packages only exist for RHEL4 and RHEL5, resp 340 and 600 projects while RPMforge builds for RHEL2, RHEL3, RHEL4 and RHEL5, about 3400 projects. We however do not provide any PPC packages.
As always, be careful what you enable and cherry pick rather than enable fully.
PS Within a corporate environment, look at the mrepo tool for managing repositories and cherry picking packages for deploying and managing systems. Do not enable repositories company wide !
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 7/28/07, drew einhorn drew.einhorn@gmail.com wrote:
Dumb question.
Can't we identify the source of the package by looking at the signature.
Yes.. but there isnt a tool that comes up with it, and there are too many people who do not have enough training to answer this question. They may have gotten a vm system that has EPEL and RPMforge installed on it and cant figure out why gogo isnt working naymore...
Hmm. We need a tool that creates repotags from signatures. Sounds like it should be a small easy project. Hope it inspires somebody. I'm too slow.
On 7/28/07, Stephen John Smoogen smooge@gmail.com wrote:
On 7/28/07, drew einhorn drew.einhorn@gmail.com wrote:
Dumb question.
Can't we identify the source of the package by looking at the signature.
Yes.. but there isnt a tool that comes up with it, and there are too many people who do not have enough training to answer this question. They may have gotten a vm system that has EPEL and RPMforge installed on it and cant figure out why gogo isnt working naymore...
-- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
drew einhorn wrote:
Dumb question.
Can't we identify the source of the package by looking at the signature.
Signature, vendor, etc... right. Pretty much why epel (so far) didn't see the need/value in the complexity/overhead of introducing repotags.
That said, my personal opinion is/was that epel *should* use them, if for no other reason so that others can't use it to support arguments of non-cooperation (too late).
-- Rex
On Sun, 29 Jul 2007, Rex Dieter wrote:
drew einhorn wrote:
Dumb question.
Can't we identify the source of the package by looking at the signature.
Signature, vendor, etc... right. Pretty much why epel (so far) didn't see the need/value in the complexity/overhead of introducing repotags.
That information is not shown by yum on dependency failures (which break yum). Not having that information in copy&paste output requires people to ask one or more questions before finding the cause and redirecting to the correct forum.
Having that information available in the output (which is impossible with the signature or vendor because of the size of the string) will make it apparent to the user having the problem where to report a problem.
Besides, what complexity/overhead does the repotag have exactly ?
But we all discussed this over and over again, just to be rebutted by the same false arguments or saying that RPM can be changed. (which it can NOT for the foreseeable future ! thank you very much)
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
Dag Wieers wrote:
On Fri, 27 Jul 2007, JC Júnior wrote:
I received a message about EPEL repository, I would like to know if this repo is long term support too.
Let me add that an effort to make sure EPEL is compatible with RPMforge failed as EPEL wants to become the only repository for RHEL and there is no interest to consider current RPMforge users.
...
EPEL refused the repotag, so one cannot easily identify where a package comes from and mixing repositories becomes harder. Since compatibility is a 2 way interaction and EPEL shows no interest, it is certain that mixing EPEL with other repositories may break something.
Interesting you say that. It's quite a stetch from "no repotags" to conclude "EPEL has no interest" in compatibility.
In fact, epel (and fedora) repo is, by design and policy, supposed to be compatible and considerate of other repos, e.g. most notably, http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration (among other project policy documents).
When I posted the aforementioned repository collaboration document to the rpmforge list(s) for comment, it received none.
-- Rex
-- Rex
Rex Dieter wrote:
Dag Wieers wrote:
On Fri, 27 Jul 2007, JC Júnior wrote:
I received a message about EPEL repository, I would like to know if this repo is long term support too.
Let me add that an effort to make sure EPEL is compatible with RPMforge failed as EPEL wants to become the only repository for RHEL and there is no interest to consider current RPMforge users.
...
EPEL refused the repotag, so one cannot easily identify where a package comes from and mixing repositories becomes harder. Since compatibility is a 2 way interaction and EPEL shows no interest, it is certain that mixing EPEL with other repositories may break something.
Interesting you say that. It's quite a stetch from "no repotags" to conclude "EPEL has no interest" in compatibility.
In fact, epel (and fedora) repo is, by design and policy, supposed to be compatible and considerate of other repos, e.g. most notably, http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration (among other project policy documents).
When I posted the aforementioned repository collaboration document to the rpmforge list(s) for comment, it received none.
As much as I don't want the CentOS list to become the place where EPEL cooperation is discussed, it is obvious what their policy is.
There is talk about cooperation and collaboration, however whenever Axel or Dag made any kind of suggestions on the EPEL list, they were not given very much "real" consideration. Certainly not the consideration that the current EXPERTS on 3rd party repositories should get. I found this especially troubling since RPMForge (and it's predecessors) and ATRPMS saw the 3rd party repo need and filled that need before Fedora even existed. The replies these repo maintainer where ... that is not how Fedora does things. EPEL is Fedora's project to do with as they see fit, so this is not really a problem. It did leave a bitter taste in my mouth on a personal level though.
There is also now this posting on the EPEL message list and wiki too:
Message list: https://www.redhat.com/archives/epel-devel-list/2007-July/msg00239.html
Wiki: http://fedoraproject.org/wiki/EPEL/FAQ#head-9ddfe705d75fe928468e3c64c1135de7... (the link does not seem to work directly ... look for "Section 2", "subsection 4", entitled "What about compatibility with other third party repositories?")
There is absolutely nothing wrong with EPEL doing whatever they want, but their policy on collaboration is really that they are the one add-on repository that all should use. Their reckoning is that all people who want to use or contribute packages should do so within their framework and guidelines. I'm sorry, but that is _NOT_ how it has to be.
Some other shortcomings have also already been addressed, but not resolved, on the EPEL list (and Red Hat is taking action to solve some of them {to give credit where credit is due}).
Issues like, What happens when someone with the "Desktop Product" tries to install foo, but foo requires bar, and bar is only in "Server Product" and not in "Desktop Product". There are only really 3 answers to this issue (well, 4 if you count use the CentOS package) and they are:
1. EPEL can provide packages in a separate part of the repo to act as glue if there are package differences between the least populated EL project (ie, Red Hat Desktop) and the most populated project (ie, RHEL AS). This does not need to be everything to upgrade (Red Hat would not like that) ... just unmet dependences for packages in EPEL. EPEL recently worked with CentOS to do just that with all the requirements to get yum and it's requirements into the EPEL repos for EL4. It is not quite as easy though if RHEL is involved (they can't upgrade desktop products to server products).
2. EPEL can say to users of the least populated project ... sorry, this doesn't work for you. They might also just not put things in the repo at all if there are unmet dependencies between versions.
3. EPEL could just create a separate repo where all deps are met for the desktop products. This would be a subset of packages from the EPEL server repo. (The CentOS policy of putting all the desktop and server packages in one repo is looking fairly good now, isn't it).
4. The people who need dependencies solved can just use a CentOS package if they can't get a dependency for something in EPEL.
Again, I am not telling anyone to not use EPEL. I personally know and like many of the people who are maintaining packages in EPEL and it will be a great asset to the EL community. Dag Wieers, Dries Verachtert and Axel Thimm are also great assets to the EL community.
What users can do is use the yum priorities plugin (yum-priorities in CentOS-5, yum-plugin-priorities in CentOS-4) and you can then get more than 1 repo to play together. For some complex installs, you may also need to use "exclude=" in your higher priority repos to get those filled by your lower priority repos.
Thanks, Johnny Hughes
Johnny Hughes wrote:
Rex Dieter wrote:
It's quite a stetch from "no repotags" to conclude "EPEL has no interest" in compatibility.
In fact, epel (and fedora) repo is, by design and policy, supposed to be compatible and considerate of other repos, e.g. most notably, http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration (among other project policy documents).
When I posted the aforementioned repository collaboration document to the rpmforge list(s) for comment, it received none.
There is talk about cooperation and collaboration, however whenever Axel or Dag made any kind of suggestions on the EPEL list, they were not given very much "real" consideration.
Only wrt to repotags. Don't remember any serious/significant discussions outside of that since. Am I missing something?
So, is rpmforge interested in collaboration or not? Does the RepositoryCollaboration sound like a reasonable starting place?
-- Rex
On Mon, Jul 30, 2007 at 03:43:31PM -0500, Rex Dieter wrote:
Johnny Hughes wrote:
Rex Dieter wrote:
It's quite a stetch from "no repotags" to conclude "EPEL has no interest" in compatibility.
In fact, epel (and fedora) repo is, by design and policy, supposed to be compatible and considerate of other repos, e.g. most notably, http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration (among other project policy documents).
When I posted the aforementioned repository collaboration document to the rpmforge list(s) for comment, it received none.
There is talk about cooperation and collaboration, however whenever Axel or Dag made any kind of suggestions on the EPEL list, they were not given very much "real" consideration.
Only wrt to repotags. Don't remember any serious/significant discussions outside of that since. Am I missing something?
Lots of things, there was even a face-to-face meeting at LT07. Where it was revealed that it was spot's fault that repotags were killed (but I guess that's just the non-present scape-goat methology)
So, is rpmforge interested in collaboration or not? Does the RepositoryCollaboration sound like a reasonable starting place?
The orginal one, yes, the current one which even lacks the presence of EPEL no.
On Mon, 30 Jul 2007, Axel Thimm wrote:
On Mon, Jul 30, 2007 at 03:43:31PM -0500, Rex Dieter wrote:
Johnny Hughes wrote:
Rex Dieter wrote:
It's quite a stetch from "no repotags" to conclude "EPEL has no interest" in compatibility.
In fact, epel (and fedora) repo is, by design and policy, supposed to be compatible and considerate of other repos, e.g. most notably, http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration (among other project policy documents).
When I posted the aforementioned repository collaboration document to the rpmforge list(s) for comment, it received none.
There is talk about cooperation and collaboration, however whenever Axel or Dag made any kind of suggestions on the EPEL list, they were not given very much "real" consideration.
Only wrt to repotags. Don't remember any serious/significant discussions outside of that since. Am I missing something?
Lots of things, there was even a face-to-face meeting at LT07. Where it was revealed that it was spot's fault that repotags were killed (but I guess that's just the non-present scape-goat methology)
Well, if I remember correctly, during that meeting Max Spevack asked why repotags were being dismissed if they fixed something that was otherwise not fixable.
After that it was apparent repotags were going to be back. Of course, it reappeared on the mailinglist and was voted down again.
The only way the repotags would have gotten through is if we could have everybody from the EPEL steering commitee together and explained them everything we did at LT07.
My believe is that repotags was not the issue. There was something else that made it impossible. And I can not undo the thought that it is because not having repotags makes EPEL authoritative and masks dependency problems.
It has an unfair advantage for the repository that does not tag its packages, and it is certainly not advantageous to the userbase.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
Dag Wieers wrote:
My believe is that repotags was not the issue. There was something else that made it impossible. And I can not undo the thought that it is because not having repotags makes EPEL authoritative and masks dependency problems.
Can you explain that? Authoritative over who/what?
It has an unfair advantage for the repository that does not tag its packages, and it is certainly not advantageous to the userbase.
Advantage at what? And if there is only one untagged repo, can't the userbase tell who to blame?
Les Mikesell wrote:
Dag Wieers wrote:
My believe is that repotags was not the issue. There was something else that made it impossible. And I can not undo the thought that it is because not having repotags makes EPEL authoritative and masks dependency problems.
Can you explain that? Authoritative over who/what?
Authoritative over the other 3rd party repos.
People have already explained this a dozen times. Lets pick a package. perl-XYZ-1.2.3.i386.rpm. People see that, they don't see a repo tag and they think, hey ... this is part of RHEL (or CentOS) ... then they see perl-XYZ-1.2.3.rf.i386.rpm trying to replace it and they say .. hey, rpmforge is replacing my core package.
Then CentOS or rpmforge field the troublecall to fix EPEL's broken package deps.
Now, imagine the same senerio with:
perl-XYZ-1.2.3.i386.epel5.rpm
fairly obvious where it came from ...
It has an unfair advantage for the repository that does not tag its packages, and it is certainly not advantageous to the userbase.
Advantage at what? And if there is only one untagged repo, can't the userbase tell who to blame?
There is not 1 untagged repo ... there are many.
The WHOLE of the OS is untagged (or the majority of it). For CentOS that is 5 repos ... for RHEL it is at least 3 channels.
When people see UNTAGGED they think ... THE MAIN OS. That is exactly what EPEL wants. They want to be part of the OS, with others repos considered as 3rd Party repos. They want to be THE AUTHORITATIVE REPO for EL. I don't know how it could be any clearer....
On Sun, Jul 29, 2007 at 03:29:11PM -0500, Rex Dieter wrote:
Dag Wieers wrote:
On Fri, 27 Jul 2007, JC Júnior wrote:
I received a message about EPEL repository, I would like to know if this repo is long term support too.
Let me add that an effort to make sure EPEL is compatible with RPMforge failed as EPEL wants to become the only repository for RHEL and there is no interest to consider current RPMforge users.
...
EPEL refused the repotag, so one cannot easily identify where a package comes from and mixing repositories becomes harder. Since compatibility is a 2 way interaction and EPEL shows no interest, it is certain that mixing EPEL with other repositories may break something.
Interesting you say that. It's quite a stetch from "no repotags" to conclude "EPEL has no interest" in compatibility.
It's not really about the topic itself, but how it was handled. And the fact that this topic was a rather effortless thing epel could had agreed to makes the non-collaboration just more obvious.
The repotag system was a common loosely agreed on interrepo coexistance mechanism with one weak spot: It takes one big bad repo to destroy it. And that's what happened.
In fact, epel (and fedora) repo is, by design and policy, supposed to be compatible and considerate of other repos, e.g. most notably, http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration (among other project policy documents).
When I posted the aforementioned repository collaboration document to the rpmforge list(s) for comment, it received none.
But you also received close to none comments from EPEL itself. In fact many 3rd party repo maintainers liked Tim Jackson's original draft (which you placed unaltered in the wiki), but not even he himself likes what this document mutated to:
https://www.redhat.com/archives/epel-devel-list/2007-May/msg00049.html
Maybe the original draft will be picked up by other projects to signal their mode of collaboration, let's see. It certainly was in thge spirit of the existing 3rd party repos.
Furthermore there have been many quotes in IRC and mail of various current EPEL steering members that they "aim higher" than the existing repos or see EPEL as the only repo long term and the like.
On the positive side one must say that Max Spevack was interested in a collaboration between EPEL and the rest of the world, but he's not forcing it onto the EPEL people.
Axel Thimm wrote:
Maybe the original draft will be picked up by other projects to signal their mode of collaboration, let's see. It certainly was in thge spirit of the existing 3rd party repos.
Maybe you should cut them a little slack considering that they are not so experienced as the rest of you...
Furthermore there have been many quotes in IRC and mail of various current EPEL steering members that they "aim higher" than the existing repos or see EPEL as the only repo long term and the like.
As long as there are policies about what can be in a repo or who can put it there, there can never be just one repo. Everyone should understand that by now.
On the positive side one must say that Max Spevack was interested in a collaboration between EPEL and the rest of the world, but he's not forcing it onto the EPEL people.
I've never quite understood why you don't just give the packages different names if they already exist in the disto-supported repo but there might be some reason to want your version instead (or besides).
On Mon, Jul 30, 2007 at 07:51:45AM -0500, Les Mikesell wrote:
Axel Thimm wrote:
Maybe the original draft will be picked up by other projects to signal their mode of collaboration, let's see. It certainly was in thge spirit of the existing 3rd party repos.
Maybe you should cut them a little slack considering that they are not so experienced as the rest of you...
Experienced in what? Hidden agendas and politics? I'm not experienced in that really. Please check the epel list where these topics were discussed over *months* and often revealed their political background instead of a "lack of experience".
Furthermore there have been many quotes in IRC and mail of various current EPEL steering members that they "aim higher" than the existing repos or see EPEL as the only repo long term and the like.
As long as there are policies about what can be in a repo or who can put it there, there can never be just one repo. Everyone should understand that by now.
On the positive side one must say that Max Spevack was interested in a collaboration between EPEL and the rest of the world, but he's not forcing it onto the EPEL people.
I've never quite understood why you don't just give the packages different names if they already exist in the disto-supported repo but there might be some reason to want your version instead (or besides).
First of all there is no distro supported repo in this context, we're talking about 3rd party repos.
Next, what use would it be to give a different name? E.g. xemacs vs xemacs-myrepo? The two packages would conflict so xemacs-myrepo has to either Conflict: or Obsolete:/Provide: with the standard name, and the end result is a worse setup than having the proper name since there will be no way back to the unadorned name unless the xemacs package starts obsoleting/providing the alternate name as well.
So there is no real improvement in obfuscating names. And I didn't even mention dependent packages that would break with perl-Bar-myrepo and libfoo-devel-myrepo instead of perl-Bar and libfoo-devel.
ATM we'll just live and let live, and there will not be any one-side effort to rectify any compatibility issues EPEL created. It's their mess, they'll have to clean it up.
Axel Thimm wrote:
Maybe the original draft will be picked up by other projects to signal their mode of collaboration, let's see. It certainly was in thge spirit of the existing 3rd party repos.
Maybe you should cut them a little slack considering that they are not so experienced as the rest of you...
Experienced in what? Hidden agendas and politics? I'm not experienced in that really. Please check the epel list where these topics were discussed over *months* and often revealed their political background instead of a "lack of experience".
I meant experience with running a repo, but experience in trying to coordinate disparate policies is probably more relevant. It just isn't going to happen and everyone might as well recognize that up front.
Next, what use would it be to give a different name? E.g. xemacs vs xemacs-myrepo?
It would be very useful to me in any case where the versions differ. I like to know what I'm running and why.
The two packages would conflict so xemacs-myrepo has to either Conflict: or Obsolete:/Provide: with the standard name, and the end result is a worse setup than having the proper name since there will be no way back to the unadorned name unless the xemacs package starts obsoleting/providing the alternate name as well.
If the package name makes the difference visible, can't I "yum remove xemacs-myrepo" and "yum install xemacs-otherrepo" depending on which I want to have installed?
So there is no real improvement in obfuscating names.
But there is an improvement if I can see and control what I install and understand the differences. The names are obfucated now since the same name can refer to any of several different things.
And I didn't even mention dependent packages that would break with perl-Bar-myrepo and libfoo-devel-myrepo instead of perl-Bar and libfoo-devel.
That's only a problem if you overwrite each other's files. Put them somewhere else. Yes, having files of the same name in different path locations can confuse people who don't understand that path order searches have been used since the invention of the tree structured directory to permit multiple versions of the same things to co-exist, but the concept isn't that difficult. It's just too bad the package managers didn't get it and had to go through contortions after realizing that there are things that people need to have multiple versions installed at the same time, like the kernel and architecture-dependent libraries.
ATM we'll just live and let live, and there will not be any one-side effort to rectify any compatibility issues EPEL created. It's their mess, they'll have to clean it up.
Live and let die, you mean - at least as far as the users are concerned. I don't think this issue has any solution other than separate namespaces.
On Mon, 30 Jul 2007, Les Mikesell wrote:
ATM we'll just live and let live, and there will not be any one-side effort to rectify any compatibility issues EPEL created. It's their mess, they'll have to clean it up.
Live and let die, you mean - at least as far as the users are concerned. I don't think this issue has any solution other than separate namespaces.
Les
Your issue belongs on another list -- the 'mark by nameing' the rpm's in a way obvious to a low sophistication user (rather than some checksum based method that does not exist) has been proposed and rejected already.
sad, but still the case. We'll be having pain for this for years and years. See: https://www.redhat.com/archives/epel-devel-list/2007-June/msg00031.html
Please read the archive and the back thread leading up to it. Several @redhat.com showed up to pack the gallery at the 'last chance' epel meeting which could have avoided this train wreck
-- Russ Herrold
-------------------- highlighted extract --------------------
00:03 < knurd> | I'm wondering if we should try a different route: ask the FPC for a official statement if repotags are fine for them ...
00:05 < spot> | we're not going to give that statement. 00:05 < spot> | just as an FYI ...
00:05 < knurd> | spot, ohh, I didn#t expect you would be around 00:05 < knurd> | spot, why? 00:05 < spot> | if you really want repotags vote on it, and we'll figure out how to implement them. ...
00:06 < spot> | its not our domain to decide whether they're ok or not, thats FESCo ...
00:06 < knurd> | spot, would you share your opnion on repotags? 00:07 < spot> | I don't know what technical problem they solve. 00:07 < dgilmore> | spot: none 00:07 < spot> | They clutter up the namespace. 00:07 < knurd> | dag tried to explain one two me, and it made a bit of sense 00:07 < nirik> | they allow end users to trivially see what repo packages are causing them conflicts/problems... or so the theory goes. 00:07 < knurd> | say there is clamav in both epel and dags repo 00:07 < dgilmore> | i dont know how any sane person can expect to mix repos providing the same packages and get a consistent and sane result 00:07 < knurd> | with different sub-packages 00:07 --> | smooge (Stephen J Smoogen) has joined #fedora-meeting 00:08 < spot> | i'd tend to agree that mixing repos with the same packagesets == BOOM 00:08 < spot> | and repotags won't resolve that.
R P Herrold wrote:
ATM we'll just live and let live, and there will not be any one-side effort to rectify any compatibility issues EPEL created. It's their mess, they'll have to clean it up.
Live and let die, you mean - at least as far as the users are concerned. I don't think this issue has any solution other than separate namespaces.
Les
Your issue belongs on another list
Sorry, but I believe that the people affected need to know about it at least as much as the people who control it.
-- the 'mark by nameing' the rpm's in a way obvious to a low sophistication user (rather than some checksum based method that does not exist) has been proposed and rejected already.
That misses the point that there may very well be reasons to want to have more than one version installed at once. Every developer should know that there are times you need to at least test 2 different versions of something on the same machine - and they generally know how to do it so they don't conflict. Sadly, the FHS guys seem to live on some planet of perfection where real world issues of version differences and places to store them don't exist, and packagers have followed along with this mistake.
sad, but still the case. We'll be having pain for this for years and years. See: https://www.redhat.com/archives/epel-devel-list/2007-June/msg00031.html
Please read the archive and the back thread leading up to it. Several @redhat.com showed up to pack the gallery at the 'last chance' epel meeting which could have avoided this train wreck
Reasons for disagreements are pretty much irrelevant to their effect. There is not much reason to ever expect everyone to agree and lots of reasons to provide a mechanism to allow them to disagree in separate spaces. Try to imagine what the internet would be like if DNS did not provide managed hierarchal namespace and anyone could usurp anyone else's domain. That's what we get when different people can put different contents into packages of the same names. And it isn't going to go away until there is a namespace based system that lets the end user choose which he wants. I'd just like to see a little less granularity in that namespace than centos vs. ubuntu...
Stupid question redux.
With some more explanation
Why not?
Make a mirror of the epel repo.
For each package in the repo. Create a repotag using the original signature. Sign the package with repotag using a new key.
Anyone wanting to mix repos. Should require signatures with the new key.
Problems will certainly remain, but I think this will help with some of the problems.
On 7/30/07, Les Mikesell lesmikesell@gmail.com wrote:
R P Herrold wrote:
ATM we'll just live and let live, and there will not be any one-side effort to rectify any compatibility issues EPEL created. It's their mess, they'll have to clean it up.
Live and let die, you mean - at least as far as the users are concerned. I don't think this issue has any solution other than separate namespaces.
Les
Your issue belongs on another list
Sorry, but I believe that the people affected need to know about it at least as much as the people who control it.
-- the 'mark by nameing' the rpm's in a way obvious to a low sophistication user (rather than some checksum based method that does not exist) has been proposed and rejected
already.
That misses the point that there may very well be reasons to want to have more than one version installed at once. Every developer should know that there are times you need to at least test 2 different versions of something on the same machine - and they generally know how to do it so they don't conflict. Sadly, the FHS guys seem to live on some planet of perfection where real world issues of version differences and places to store them don't exist, and packagers have followed along with this mistake.
sad, but still the case. We'll be having pain for this for years and years. See: https://www.redhat.com/archives/epel-devel-list/2007-June/msg00031.html
Please read the archive and the back thread leading up to it. Several @redhat.com showed up to pack the gallery at the 'last chance' epel meeting which could have avoided this train wreck
Reasons for disagreements are pretty much irrelevant to their effect. There is not much reason to ever expect everyone to agree and lots of reasons to provide a mechanism to allow them to disagree in separate spaces. Try to imagine what the internet would be like if DNS did not provide managed hierarchal namespace and anyone could usurp anyone else's domain. That's what we get when different people can put different contents into packages of the same names. And it isn't going to go away until there is a namespace based system that lets the end user choose which he wants. I'd just like to see a little less granularity in that namespace than centos vs. ubuntu...
-- Les Mikesell lesmikesell@gmail.com
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, Jul 30, 2007 at 11:21:10AM -0500, Les Mikesell wrote:
ATM we'll just live and let live, and there will not be any one-side effort to rectify any compatibility issues EPEL created. It's their mess, they'll have to clean it up.
Live and let die, you mean - at least as far as the users are concerned.
Nah, while I was a James Bond fan in my early youth, I'm not a fan of repo wars. "Let live" was all right, there will not be a war, but neither any one-sided fixing army on this.
I don't think this issue has any solution other than separate namespaces.
Looking at your requests on this you should realize that repotags are what you are really asking for the minimum level, which is what epel nuked to ashes. So the discussion should probably move away from this list to the epel list. And since it's a dead topic there as well you will not really get very far.
Looking at your requests on this you should realize that repotags are what you are really asking for the minimum level, which is what epel nuked to ashes. So the discussion should probably move away from this list to the epel list. And since it's a dead topic there as well you will not really get very far.
I know EPEL acknowledged that the whole repo-conflicts thing is an issue that needed to be addressed... as has been rehashed many times, they just didn't like repotags.
However, perhaps adding something into RPM itself could go a long way to addressing this in a more integrated manner?
https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01537.html
That thread might be a good place to request that something like this be added.
Not sure how high of a priority everyone would consider it.
Ray
On Mon, Jul 30, 2007 at 12:15:31PM -0700, Ray Van Dolson wrote:
I know EPEL acknowledged that the whole repo-conflicts thing is an issue that needed to be addressed... as has been rehashed many times, they just didn't like repotags.
The history goes as follows:
o Dag suggests repotags, Axel back them up o _very_ long discussion about repotags o repotags get killed by epel, lots of pain for the repos that did carry repotags (at least for ATrpms it was a painful transition) o Many repo maintainers and users complain about epel's lack of cooperation o epel suddenly reconsiders
So after the fact everyone can claim anything. The important thing is how did epel (or better said certain key persons in there) deal with it when they did not see the political ramifications they inflicted upon themselves?
On Mon, Jul 30, 2007 at 11:08:49PM +0200, Axel Thimm wrote:
On Mon, Jul 30, 2007 at 12:15:31PM -0700, Ray Van Dolson wrote:
I know EPEL acknowledged that the whole repo-conflicts thing is an issue that needed to be addressed... as has been rehashed many times, they just didn't like repotags.
The history goes as follows:
o Dag suggests repotags, Axel back them up o _very_ long discussion about repotags o repotags get killed by epel, lots of pain for the repos that did carry repotags (at least for ATrpms it was a painful transition) o Many repo maintainers and users complain about epel's lack of cooperation o epel suddenly reconsiders
So after the fact everyone can claim anything. The important thing is how did epel (or better said certain key persons in there) deal with it when they did not see the political ramifications they inflicted upon themselves?
I understand how a lot of it "went down" (saw the meetings and am on the lists as well), I'm just wondering if that aside (I know, hard to do :), could there feasibly be an RPM-based solution to this that would make repo-tags obsolete?
Ray
On 7/30/07, Ray Van Dolson rvandolson@esri.com wrote:
On Mon, Jul 30, 2007 at 11:08:49PM +0200, Axel Thimm wrote:
So after the fact everyone can claim anything. The important thing is how did epel (or better said certain key persons in there) deal with it when they did not see the political ramifications they inflicted upon themselves?
I understand how a lot of it "went down" (saw the meetings and am on the lists as well), I'm just wondering if that aside (I know, hard to do :), could there feasibly be an RPM-based solution to this that would make repo-tags obsolete?
Not sure if in RPM itself (in its current incarnations). It would be sort of a layer above it that at its simplest is the yum priorities list.. and in a more complicated version would rank against rpm signatures so that package X with X1 signature could not replace anything with Y1 signatures.
However, even if it were possible, I doubt it would stop it being brought up every couple of weeks..
On Mon, Jul 30, 2007 at 03:20:49PM -0600, Stephen John Smoogen wrote:
On 7/30/07, Ray Van Dolson rvandolson@esri.com wrote:
On Mon, Jul 30, 2007 at 11:08:49PM +0200, Axel Thimm wrote:
So after the fact everyone can claim anything. The important thing is how did epel (or better said certain key persons in there) deal with it when they did not see the political ramifications they inflicted upon themselves?
I understand how a lot of it "went down" (saw the meetings and am on the lists as well), I'm just wondering if that aside (I know, hard to do :), could there feasibly be an RPM-based solution to this that would make repo-tags obsolete?
Not sure if in RPM itself (in its current incarnations). It would be sort of a layer above it that at its simplest is the yum priorities list.. and in a more complicated version would rank against rpm signatures so that package X with X1 signature could not replace anything with Y1 signatures.
Only reason I ask about the RPM-based solution is that (at least to me) it would seem to be the cleanest way to do it -- to store the equivalent of the "repository" or origination inside a defined field within the RPM... something that could be actually spit out via a queryformat query.
And the RPM guys are actively seeking feature suggestions right now. It doesn't seem to me this would be too hard, but I'm _far_ from knowledgeable on RPM-internals so maybe there are other hurdles.
However, even if it were possible, I doubt it would stop it being brought up every couple of weeks..
I don't anticipate bridges ever being fully mended over this unfortunately, but it would be nice to move past it if possible and look at other technical solutions to the issue. I think most people agreed the repotag was a temoprary solution at best....
Ray
On Mon, Jul 30, 2007 at 02:12:43PM -0700, Ray Van Dolson wrote:
I understand how a lot of it "went down" (saw the meetings and am on the lists as well), I'm just wondering if that aside (I know, hard to do :), could there feasibly be an RPM-based solution to this that would make repo-tags obsolete?
Sure, but repotag are not the real issue, they were just the tip of the iceberg that rammed the Titanic. The discussion about them revealed certain aspects of EPEL or at least key persons inside EPEL that showed that there is no real interest in cooperating with other repos other than helping EPEL during the startup phase.
EPEL created in RHEL-land the same rift that fedora.us created years back in Fedora-land. So maybe even the success of fedora.us is an ethically questionable roadmap for EPEL for dealing with repo-darwinism.
Fedora.us ignored the existance of other repos and solely concentrated on their own growth while the other repos tried to remain compatible. This time the burden will not be pushed away, if EPEL breaks something they will have to fix it.
So to get back to the original question: Should RPMforge and EPEL be mixed? Please ask EPEL on this and about the (lack of) guaranty that EPEL will not break RPMforge (or any other repo).
On Mon, 30 Jul 2007, Ray Van Dolson wrote:
I understand how a lot of it "went down" (saw the meetings and am on the lists as well), I'm just wondering if that aside (I know, hard to do :), could there feasibly be an RPM-based solution to this that would make repo-tags obsolete?
'could be'? Sure. Check the package signing key against a well maintained index of the same, posibly on an automated basis with a small tool-let (TUI and widget). Have a well maintained central archive to query against, which accepts new keys countersigned with a GPG key off record at a public keyserver, from a person in a chain of trust/chain of 'known'. Lock the network down with a CACert CA mediated SSL layer.
Likely to happen? dunno -- step up and write it. I cannot write it for free. There have been proposals along these lines in one form or another, and the widget hasn't happened yet.
Until then, externally visible repotags were the next best option. But they are 'unsightly' to the Red Hat person quoted, as they "clutter up the namespace". Fine. He wins. We all lose.
Tech support load sauce for the goose works on the gander as well. I assume Dag and Axel will have to send people away when it is EPEL is present or conflicting for load management.
-- Russ Herrold
On Mon, 30 Jul 2007, Ray Van Dolson wrote:
Looking at your requests on this you should realize that repotags are what you are really asking for the minimum level, which is what epel nuked to ashes. So the discussion should probably move away from this list to the epel list. And since it's a dead topic there as well you will not really get very far.
I know EPEL acknowledged that the whole repo-conflicts thing is an issue that needed to be addressed... as has been rehashed many times, they just didn't like repotags.
However, perhaps adding something into RPM itself could go a long way to addressing this in a more integrated manner?
https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01537.html
That thread might be a good place to request that something like this be added.
Not sure how high of a priority everyone would consider it.
Ray,
the problem is that with a Fedora mentality you are not fixing anything until RHEL5 goes EOL. (somewhere in 2014 I think ?)
So yes, welcome to the RHEL world where workarounds are required because Red Hat has no incentive to add features.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
Axel Thimm wrote:
I don't think this issue has any solution other than separate namespaces.
Looking at your requests on this you should realize that repotags are what you are really asking for the minimum level, which is what epel nuked to ashes. So the discussion should probably move away from this list to the epel list. And since it's a dead topic there as well you will not really get very far.
I don't know enough about repotags to understand why everyone needs them. Can't any repotag be distinguished from no repotag? Why is there any need for cooperation beyond not choosing the same tag or lack thereof?
On Mon, Jul 30, 2007 at 03:57:23PM -0500, Les Mikesell wrote:
Axel Thimm wrote:
I don't think this issue has any solution other than separate namespaces.
Looking at your requests on this you should realize that repotags are what you are really asking for the minimum level, which is what epel nuked to ashes. So the discussion should probably move away from this list to the epel list. And since it's a dead topic there as well you will not really get very far.
I don't know enough about repotags to understand why everyone needs them. Can't any repotag be distinguished from no repotag? Why is there any need for cooperation beyond not choosing the same tag or lack thereof?
All the repotags request was about is to idntify epel packages as such with a simple tag in the file name, no more, no less. And that already died with an awful sound.
Axel Thimm wrote:
I don't know enough about repotags to understand why everyone needs them. Can't any repotag be distinguished from no repotag? Why is there any need for cooperation beyond not choosing the same tag or lack thereof?
All the repotags request was about is to idntify epel packages as such with a simple tag in the file name, no more, no less. And that already died with an awful sound.
If everyone else has added unique repo tags, isn't the lack of a tag an equally unique identifier? I'm missing the point of argument here.
On Mon, Jul 30, 2007 at 04:58:19PM -0500, Les Mikesell wrote:
Axel Thimm wrote:
I don't know enough about repotags to understand why everyone needs them. Can't any repotag be distinguished from no repotag? Why is there any need for cooperation beyond not choosing the same tag or lack thereof?
All the repotags request was about is to idntify epel packages as such with a simple tag in the file name, no more, no less. And that already died with an awful sound.
If everyone else has added unique repo tags, isn't the lack of a tag an equally unique identifier? I'm missing the point of argument here.
So you want to reiterate the whole epel-devel repotag fiasco here argument by argument? The argument was that once a repo drops the repotag and foo-1.2.3-4 conflicts with foo-2.0.0-1.blahrepo the typical user assumes the former to belong to the distro proper and the latter to be the one causing the conflict.
This is no academia, freshrpms had dropped repotags in December and suddely it started to rain such bug reports like "ATrpms replaces Fedora's mplayer".
But really this becomes more and more off-topic and a repetition of the epel-devel list discussion. If you have more questions on the nature of repotags and the repo rifts created by epel, please check the epel archives. Be assured that every aspect has been brought up and beaten to death.
Axel Thimm wrote:
On Mon, Jul 30, 2007 at 04:58:19PM -0500, Les Mikesell wrote:
Axel Thimm wrote:
I don't know enough about repotags to understand why everyone needs them. Can't any repotag be distinguished from no repotag? Why is there any need for cooperation beyond not choosing the same tag or lack thereof?
All the repotags request was about is to idntify epel packages as such with a simple tag in the file name, no more, no less. And that already died with an awful sound.
If everyone else has added unique repo tags, isn't the lack of a tag an equally unique identifier? I'm missing the point of argument here.
So you want to reiterate the whole epel-devel repotag fiasco here argument by argument?
No, I want to understand the effect on an end user when only one repo refuses to add a unique tag. I don't want to fight the war - I want to know which way to duck.
The argument was that once a repo drops the repotag and foo-1.2.3-4 conflicts with foo-2.0.0-1.blahrepo the typical user assumes the former to belong to the distro proper and the latter to be the one causing the conflict.
I don't get it. What does the potential to drop a tag have to do with a tag not existing in the first place?
No, I want to understand the effect on an end user when only one repo refuses to add a unique tag. I don't want to fight the war - I want to know which way to duck.
I think the issue now is that other repo's decided to drop their own repo tags as a result of EPEL's decision. So that could potentially lead to some conflict.
I think a lot of this stems from the fact that EPEL considered themselves a bit like Fedora Extras aka "upstream" in a sense. Which actually seemed somewhat to make sense to me, but...
The argument was that once a repo drops the repotag and foo-1.2.3-4 conflicts with foo-2.0.0-1.blahrepo the typical user assumes the former to belong to the distro proper and the latter to be the one causing the conflict.
I don't get it. What does the potential to drop a tag have to do with a tag not existing in the first place?
I think in general it's just not a good idea to mix repo's at all -- and if you do to only selectively enable the packages you want.
Ray
On Mon, 30 Jul 2007, Ray Van Dolson wrote:
No, I want to understand the effect on an end user when only one repo refuses to add a unique tag. I don't want to fight the war - I want to know which way to duck.
I think the issue now is that other repo's decided to drop their own repo tags as a result of EPEL's decision. So that could potentially lead to some conflict.
I think a lot of this stems from the fact that EPEL considered themselves a bit like Fedora Extras aka "upstream" in a sense. Which actually seemed somewhat to make sense to me, but...
EPEL does not do RHEL2 nor does RHEL3. Much like Fedora Legacy you may see that there is a big interest in RHEL5, and when RHEL6 comes out, and then RHEL7 the interest moves on.
RHEL5 will become the RHEL2 of today.
I don't see Fedora EPEL as upstream, but I may be alone in that.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On Mon, 30 Jul 2007, Les Mikesell wrote:
Axel Thimm wrote:
On Mon, Jul 30, 2007 at 04:58:19PM -0500, Les Mikesell wrote:
Axel Thimm wrote:
I don't know enough about repotags to understand why everyone needs them. Can't any repotag be distinguished from no repotag? Why is there any need for cooperation beyond not choosing the same tag or lack thereof?
All the repotags request was about is to idntify epel packages as such with a simple tag in the file name, no more, no less. And that already died with an awful sound.
If everyone else has added unique repo tags, isn't the lack of a tag an equally unique identifier? I'm missing the point of argument here.
So you want to reiterate the whole epel-devel repotag fiasco here argument by argument?
No, I want to understand the effect on an end user when only one repo refuses to add a unique tag. I don't want to fight the war - I want to know which way to duck.
Red Hat does not add tags, so there are at least 2 parties that do not add tags. Red Hat and Fedora EPEL. So yes, that makes it harder for people to know if a package came with the OS or with EPEL.
From a debugging dependency point of view this is equally disturbing.
The argument was that once a repo drops the repotag and foo-1.2.3-4 conflicts with foo-2.0.0-1.blahrepo the typical user assumes the former to belong to the distro proper and the latter to be the one causing the conflict.
I don't get it. What does the potential to drop a tag have to do with a tag not existing in the first place?
EPEL and RPMforge have the same packages, but not the same set if subpackages and interdependencies. If there is no repotag, packages could depend on subpackages from another repository where it makes no sense. The clamav packages are an excellent example. Please read the EPEL mailinglist for this example.
As a result of this and other examples, EPEL's advice is not to mix repositories (which fits nicely in their agenda). So there is an important advantage for not having repotags, it favors their repository because in dependency problem output you see non-tagged packages and rf-tagged packages. Who do you think people are going to blame.
And this is not just fake drama, we have been there with Fedora Extras. This strategy pushed away most 3rd party repositories.
You may argue that that is a good thing. But Fedora is a different beast than RHEL. People may want stable packages, or current packages and a single repository (with the tools we have today) cannot provide this.
Besides, it punishes people who did not have an alternative back when Fedora Extras refused to do RHEL packages and only had RPMforge to fall back on.
At least that's my point of view.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
Dag Wieers wrote:
You may argue that that is a good thing. But Fedora is a different beast than RHEL. People may want stable packages, or current packages and a single repository (with the tools we have today) cannot provide this.
But people may want _both_ the stable package and the current package on the same machine at the same time. Having a hint of the difference barely visible in the package name doesn't help a bit.
Besides, it punishes people who did not have an alternative back when Fedora Extras refused to do RHEL packages and only had RPMforge to fall back on.
At least that's my point of view.
I think you are making too much out of name differences for things that can clobber each other and not enough about ways to let the different things co-exist - on the same machines if you want them, or to let users choose which they want. If two same-named packages can conflict, someone did something wrong and the issue shouldn't be about who did it but how to avoid it.
Les Mikesell wrote:
Dag Wieers wrote:
You may argue that that is a good thing. But Fedora is a different beast than RHEL. People may want stable packages, or current packages and a single repository (with the tools we have today) cannot provide this.
But people may want _both_ the stable package and the current package on the same machine at the same time. Having a hint of the difference barely visible in the package name doesn't help a bit.
I cannot see how it is possible to install both the stable package and current package.
Besides, it punishes people who did not have an alternative back when Fedora Extras refused to do RHEL packages and only had RPMforge to fall back on.
At least that's my point of view.
I think you are making too much out of name differences for things that can clobber each other and not enough about ways to let the different things co-exist - on the same machines if you want them, or to let users choose which they want. If two same-named packages can conflict, someone did something wrong and the issue shouldn't be about who did it but how to avoid it.
I disagree. If I was going to roll my own packages in my own repository to overrule the OS repositories, tagging my packages would be essential.
Feizhou wrote:
Les Mikesell wrote:
Dag Wieers wrote:
You may argue that that is a good thing. But Fedora is a different beast than RHEL. People may want stable packages, or current packages and a single repository (with the tools we have today) cannot provide this.
But people may want _both_ the stable package and the current package on the same machine at the same time. Having a hint of the difference barely visible in the package name doesn't help a bit.
I cannot see how it is possible to install both the stable package and current package.
How many kernel packages do you have installed? All it takes is to not write the same-named file in the same place as the other package. In some cases there are practical problems where a service needs to listen on a default port and you can't run 2 at once, or the init script is expected to live in a certain place so we'd need a creative solution, but most files could just have their own unique path and you'd pick the one you want with your PATH setting - something well understood decades ago.
Besides, it punishes people who did not have an alternative back when Fedora Extras refused to do RHEL packages and only had RPMforge to fall back on.
At least that's my point of view.
I think you are making too much out of name differences for things that can clobber each other and not enough about ways to let the different things co-exist - on the same machines if you want them, or to let users choose which they want. If two same-named packages can conflict, someone did something wrong and the issue shouldn't be about who did it but how to avoid it.
I disagree. If I was going to roll my own packages in my own repository to overrule the OS repositories, tagging my packages would be essential.
But the tags are in an inconvenient position to control anything. How do you ensure that you'll get your copies if any other repo adds a newer release? Normally you'd want updates to float to the latest.
On Wed, 1 Aug 2007, Les Mikesell wrote:
Feizhou wrote:
Les Mikesell wrote:
Dag Wieers wrote:
You may argue that that is a good thing. But Fedora is a different beast than RHEL. People may want stable packages, or current packages and a single repository (with the tools we have today) cannot provide this.
But people may want _both_ the stable package and the current package on the same machine at the same time. Having a hint of the difference barely visible in the package name doesn't help a bit.
I cannot see how it is possible to install both the stable package and current package.
How many kernel packages do you have installed? All it takes is to not write the same-named file in the same place as the other package. In some cases there are practical problems where a service needs to listen on a default port and you can't run 2 at once, or the init script is expected to live in a certain place so we'd need a creative solution, but most files could just have their own unique path and you'd pick the one you want with your PATH setting - something well understood decades ago.
RPM allows it, but for anything else the depsolver needs to be modified to allow it. And even if you allow it, there is no policy of what needs to be updated and how. For the kernel there is a lot of specialized logic to make it work.
While I agree with you that it is possible (in RPM) and can be useful, I do not agree that it is a solution to the repository mixing problem.
Besides, it punishes people who did not have an alternative back when Fedora Extras refused to do RHEL packages and only had RPMforge to fall back on.
At least that's my point of view.
I think you are making too much out of name differences for things that can clobber each other and not enough about ways to let the different things co-exist - on the same machines if you want them, or to let users choose which they want. If two same-named packages can conflict, someone did something wrong and the issue shouldn't be about who did it but how to avoid it.
I disagree. If I was going to roll my own packages in my own repository to overrule the OS repositories, tagging my packages would be essential.
But the tags are in an inconvenient position to control anything. How do you ensure that you'll get your copies if any other repo adds a newer release? Normally you'd want updates to float to the latest.
Correct, you would think Fedora took care of this, right ? But there is no interest for Fedora to take care of that because they want to be the only repository. It is not something they have an incentive for to fix.
That is exactly the problem. The repotag would be a workaround (and a convenient one for users) but the real changes need to be in yum or somewhere else. And Fedora does not care, so RHEL will not have it.
I have warned for this on the Feodra mailinglist years ago. There just is no interest to have the diversity of more than one repository.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
Dag Wieers wrote:
I cannot see how it is possible to install both the stable package and current package.
How many kernel packages do you have installed? All it takes is to not write the same-named file in the same place as the other package. In some cases there are practical problems where a service needs to listen on a default port and you can't run 2 at once, or the init script is expected to live in a certain place so we'd need a creative solution, but most files could just have their own unique path and you'd pick the one you want with your PATH setting - something well understood decades ago.
RPM allows it, but for anything else the depsolver needs to be modified to allow it. And even if you allow it, there is no policy of what needs to be updated and how. For the kernel there is a lot of specialized logic to make it work.
While I agree with you that it is possible (in RPM) and can be useful, I do not agree that it is a solution to the repository mixing problem.
It is the solution for cases where there are known differences in packages and only the end user/admin can make the right choice about which or how many of them he wants. That obviously can't be automated, although I've always wanted to see a way to track exactly the package/versions that one system has installed and reproduce it on any number of other systems. In that scenario, an expert sysadmin could hand-tune a system for a certain set of functions, publish his configuration, and any number of other people could have equally well tuned systems that duplicated the setup and tracked the same updates. The end user would then have to choose nothing but his virtual representative sysadmin.
You'll have to remind me why anyone wants different same-named packages with differences the end user doesn't understand and can't control to exist at all before I can comment on a solution about managing them.
I think you are making too much out of name differences for things that can clobber each other and not enough about ways to let the different things co-exist - on the same machines if you want them, or to let users choose which they want. If two same-named packages can conflict, someone did something wrong and the issue shouldn't be about who did it but how to avoid it.
I disagree. If I was going to roll my own packages in my own repository to overrule the OS repositories, tagging my packages would be essential.
But the tags are in an inconvenient position to control anything. How do you ensure that you'll get your copies if any other repo adds a newer release? Normally you'd want updates to float to the latest.
Correct, you would think Fedora took care of this, right ? But there is no interest for Fedora to take care of that because they want to be the only repository. It is not something they have an incentive for to fix.
That is exactly the problem. The repotag would be a workaround (and a convenient one for users) but the real changes need to be in yum or somewhere else. And Fedora does not care, so RHEL will not have it.
I have warned for this on the Feodra mailinglist years ago. There just is no interest to have the diversity of more than one repository.
What value does diversity add when the end user can't select which one he wants or load all of them? I understand the scenario where a single repository has a policy that prohibits certain packages from being included, but the only conflicts in those cases should be where an incomplete version is packaged in one place under the same name as the full version in a place with a different policy. The more common case would just be additional packages or packages with different names.
From an end-user viewpoint, I can't see why anyone would want to maintain a potentially-conflicting package of something that can be freely distributed and keep it in an isolated repository, especially without any mechanism to control which will be installed. Can you explain the reason anyone would want to have diversity instead of a single maintainer per package and the same packages in all repositories whose policies find them acceptable?
Les Mikesell napsal(a):
Correct, you would think Fedora took care of this, right ? But there is no interest for Fedora to take care of that because they want to be the only repository. It is not something they have an incentive for to fix.
That is exactly the problem. The repotag would be a workaround (and a convenient one for users) but the real changes need to be in yum or somewhere else. And Fedora does not care, so RHEL will not have it.
I have warned for this on the Feodra mailinglist years ago. There just is no interest to have the diversity of more than one repository.
What value does diversity add when the end user can't select which one he wants or load all of them? I understand the scenario where a single repository has a policy that prohibits certain packages from being included, but the only conflicts in those cases should be where an incomplete version is packaged in one place under the same name as the full version in a place with a different policy. The more common case would just be additional packages or packages with different names.
From an end-user viewpoint, I can't see why anyone would want to maintain a potentially-conflicting package of something that can be freely distributed and keep it in an isolated repository, especially without any mechanism to control which will be installed. Can you explain the reason anyone would want to have diversity instead of a single maintainer per package and the same packages in all repositories whose policies find them acceptable?
Diversity adds a lot of value. If EPEL will be only repo nobody on RHEL workstation can see/listen MP3, WMA, DVD playing, because of interesting US software patent and millenium act law.
Petr "Qaxi" Klíma wrote:
Les Mikesell napsal(a):
Correct, you would think Fedora took care of this, right ? But there is no interest for Fedora to take care of that because they want to be the only repository. It is not something they have an incentive for to fix.
That is exactly the problem. The repotag would be a workaround (and a convenient one for users) but the real changes need to be in yum or somewhere else. And Fedora does not care, so RHEL will not have it.
I have warned for this on the Feodra mailinglist years ago. There just is no interest to have the diversity of more than one repository.
What value does diversity add when the end user can't select which one he wants or load all of them? I understand the scenario where a single repository has a policy that prohibits certain packages from being included, but the only conflicts in those cases should be where an incomplete version is packaged in one place under the same name as the full version in a place with a different policy. The more common case would just be additional packages or packages with different names.
From an end-user viewpoint, I can't see why anyone would want to maintain a potentially-conflicting package of something that can be freely distributed and keep it in an isolated repository, especially without any mechanism to control which will be installed. Can you explain the reason anyone would want to have diversity instead of a single maintainer per package and the same packages in all repositories whose policies find them acceptable?
Diversity adds a lot of value. If EPEL will be only repo nobody on RHEL workstation can see/listen MP3, WMA, DVD playing, because of interesting US software patent and millenium act law.
That's not what I meant. Obviously we need additional packages in other repositories and that will be true as long as there is any policy that might exclude any contribution to a centrally managed repository. The question is, why do we need/want different versions of the same-named packages, or packages that provide different versions of the same files that can overwrite each other based on conditions we can't control? There probably is a good reason to want this - I just can't think of it right now.
That's not what I meant. Obviously we need additional packages in other repositories and that will be true as long as there is any policy that might exclude any contribution to a centrally managed repository. The question is, why do we need/want different versions of the same-named packages, or packages that provide different versions of the same files that can overwrite each other based on conditions we can't control? There probably is a good reason to want this - I just can't think of it right now.
We don't. That is why we need tags since we do not track every package in every repo. Having tags allows pinpointing from which repo the 'problem' package comes from and then setting appropriate yum configs...
Diversity adds a lot of value. If EPEL will be only repo nobody on RHEL workstation can see/listen MP3, WMA, DVD playing, because of interesting US software patent and millenium act law.
That's not what I meant. Obviously we need additional packages in other repositories and that will be true as long as there is any policy that might exclude any contribution to a centrally managed repository. The question is, why do we need/want different versions of the same-named packages, or packages that provide different versions of the same files that can overwrite each other based on conditions we can't control? There probably is a good reason to want this - I just can't think of it right now.
That's easy:
(this is example, has no reflection to current state ...)
EPEL provides xmms-1.2.10-1.i586.rpm - but without MP3, WMA, AAC ... DAG provides xmms-1.2.9-1.rf.i586.rpm - with all those beasts ATRPM provides xmms-1.2.10-1.at.i586.rpm - with all those beasts
Which you installs? Who knows, probably EPEL ...
Solution?
Repo priorities and includes
[base] name=CentOS-$releasever - Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos4 *priority=1*
# Name: RPMforge RPM Repository for Red Hat Enterprise 4 - dag # URL: http://rpmforge.net/ [rpmforge-CO] name = RPMforge.net-EL 4 mirrorlist = http://apt.sw.be/redhat/el4/en/mirrors-rpmforge gpgkey = http://dag.wieers.com/packages/RPM-GPG-KEY.dag.txt gpgcheck = 1 enabled = 0 *priority=80* *includepkgs=xmms**
[epel] name=Extra Packages for Enterprise Linux 5 - $basearch #baseurl=http://download.fedora.redhat.com/pub/epel/5/$basearch mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=$basearch failovermethod=priority enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL *priority=99* *# this is yust for sure priprities should do it better* *exclude=xmms**
Petr "Qaxi" Klíma wrote:
Diversity adds a lot of value. If EPEL will be only repo nobody on RHEL workstation can see/listen MP3, WMA, DVD playing, because of interesting US software patent and millenium act law.
That's not what I meant. Obviously we need additional packages in other repositories and that will be true as long as there is any policy that might exclude any contribution to a centrally managed repository. The question is, why do we need/want different versions of the same-named packages, or packages that provide different versions of the same files that can overwrite each other based on conditions we can't control? There probably is a good reason to want this - I just can't think of it right now.
That's easy:
(this is example, has no reflection to current state ...)
EPEL provides xmms-1.2.10-1.i586.rpm - but without MP3, WMA, AAC ... DAG provides xmms-1.2.9-1.rf.i586.rpm - with all those beasts ATRPM provides xmms-1.2.10-1.at.i586.rpm - with all those beasts
Which you installs? Who knows, probably EPEL ...
Solution?
Repo priorities and includes
But wouldn't it be easier if the packages had different names so you could just install the one(s) you want from the command line?
Repo priorities and includes
But wouldn't it be easier if the packages had different names so you could just install the one(s) you want from the command line?
Try your own custom postfix with a different name and see what breaks.
(this is example, has no reflection to current state ...)
EPEL provides xmms-1.2.10-1.i586.rpm - but without MP3, WMA, AAC ... DAG provides xmms-1.2.9-1.rf.i586.rpm - with all those beasts ATRPM provides xmms-1.2.10-1.at.i586.rpm - with all those beasts
Which you installs? Who knows, probably EPEL ...
Solution?
Repo priorities and includes
But wouldn't it be easier if the packages had different names so you could just install the one(s) you want from the command line?
Please suggest an easy to handle inter repo clean system how to rename XMMS packages on top of this page .
Les Mikesell wrote:
Petr "Qaxi" Klíma wrote:
Diversity adds a lot of value. If EPEL will be only repo nobody on RHEL workstation can see/listen MP3, WMA, DVD playing, because of interesting US software patent and millenium act law.
That's not what I meant. Obviously we need additional packages in other repositories and that will be true as long as there is any policy that might exclude any contribution to a centrally managed repository. The question is, why do we need/want different versions of the same-named packages, or packages that provide different versions of the same files that can overwrite each other based on conditions we can't control? There probably is a good reason to want this - I just can't think of it right now.
That's easy:
(this is example, has no reflection to current state ...)
EPEL provides xmms-1.2.10-1.i586.rpm - but without MP3, WMA, AAC ... DAG provides xmms-1.2.9-1.rf.i586.rpm - with all those beasts ATRPM provides xmms-1.2.10-1.at.i586.rpm - with all those beasts
Which you installs? Who knows, probably EPEL ...
Solution?
Repo priorities and includes
But wouldn't it be easier if the packages had different names so you could just install the one(s) you want from the command line?
NO ... because many other packages might depend on xmms (to use your example). xmms-devel might be needed to build against. All the other packages that need it (some in ATRPMS, some in RPMForge, some in Base, soem in KBS, some in EPEL) all think it provides xmms-devel or xmms. One could provide:xmms with the package ... however then it would ACT like it was named xmms too (which would make them the same).
If we change the %{name} then all of those are broken ... of we change the %{release} (ie ... add a repo tag) then all the other programs are not broken.
Also a reason for providing packages named the same thing is to provide "repo closure". That concept is to provide all packages (besides those in the main OS) that all packages in your repo need to install. Sticking with our example, xmms might require perl-Magic to install and perl-Magic is missing from BASE. You need perl-Magic to get xmms to install ... and it is in other repos (Maybe EPEL) but you don't want to force your users to also use EPEL, so you need to have perl-Magic also in your repo.
===============
It is also well beyond the scope of any distribution or repo to try and create "one-off" packages. What I consider "one-off" are things in different paths (like /opt) that allow 2 packages to be installed at the same time.
This kind of situation rapid develops into the stuff that very experienced admins need to create for their specific installation. I would be for the same problems as above ... other packages require / expect xmms-1.2.3.so.1.1.2 and they expect it in /usr/lib (or /usr/lib64) ... my renamed and relocated package can't be there. (Since you also have xmms from EPEL installed). You would need to rebuild any other packages to look at my new name/location if you wanted it to use my "one-off" package instead of the default location). That is fine if you need it for a specific reason ... it is not fine for normal installs.
Johnny Hughes wrote:
Solution?
Repo priorities and includes
But wouldn't it be easier if the packages had different names so you could just install the one(s) you want from the command line?
NO ... because many other packages might depend on xmms (to use your example). xmms-devel might be needed to build against. All the other packages that need it (some in ATRPMS, some in RPMForge, some in Base, soem in KBS, some in EPEL) all think it provides xmms-devel or xmms. One could provide:xmms with the package ... however then it would ACT like it was named xmms too (which would make them the same).
If we change the %{name} then all of those are broken ... of we change the %{release} (ie ... add a repo tag) then all the other programs are not broken.
I thought once upon a time some repo had a package named xmms-mp3 which was different from the core version for obvious reasons. I can't recall a problem and I didn't have to know which repo I had to manage to get or exclude it.
It is also well beyond the scope of any distribution or repo to try and create "one-off" packages. What I consider "one-off" are things in different paths (like /opt) that allow 2 packages to be installed at the same time.
This kind of situation rapid develops into the stuff that very experienced admins need to create for their specific installation.
You mean like every Mac user that installs an add-on package by clicking to open it's disk-image distribution and dragging it to a local location?
I thought once upon a time some repo had a package named xmms-mp3 which was different from the core version for obvious reasons. I can't recall a problem and I didn't have to know which repo I had to manage to get or exclude it.
How are we supposed to know whether or not that is a sub-package like cyrus-sasl-md5 or cyrus-sasl-plain?
This kind of situation rapid develops into the stuff that very experienced admins need to create for their specific installation.
You mean like every Mac user that installs an add-on package by clicking to open it's disk-image distribution and dragging it to a local location?
Hey that is unfair. That is only possible because dependencies and what not are already dealt with. Those packages will just work.
On Wed, Aug 01, 2007 at 11:29:25AM -0500, Les Mikesell wrote:
You'll have to remind me why anyone wants different same-named packages with differences the end user doesn't understand and can't control to exist at all before I can comment on a solution about managing them.
Let's assume no one wants that (I think I don't). Shouldn't you be chasing the repo that just created the duplicates instead of the ones that supported RHEL/CentOS over years now?
And before you rightfully extend the argument - as far as duplicates between RPMForge/Dag, Dries, Karan Extras, CentOS Extras SL contrib and ATrpms are concerned: We're working *together* on eliminating them. We're too old for clone wars, the only kid on the block that wants to play by its own rules is on another list, go patronize it ;)
Axel Thimm wrote:
On Wed, Aug 01, 2007 at 11:29:25AM -0500, Les Mikesell wrote:
You'll have to remind me why anyone wants different same-named packages with differences the end user doesn't understand and can't control to exist at all before I can comment on a solution about managing them.
Let's assume no one wants that (I think I don't). Shouldn't you be chasing the repo that just created the duplicates instead of the ones that supported RHEL/CentOS over years now?
And before you rightfully extend the argument - as far as duplicates between RPMForge/Dag, Dries, Karan Extras, CentOS Extras SL contrib and ATrpms are concerned: We're working *together* on eliminating them.
And yet, conflicts have always kept popping up, and I can't see any provision you make to enable additional repositories to exist without coordinating with your rules. The issue is that there is only one namespace which is the part that doesn't make sense and can't work without a single authority or a hierarchial structure, and I can't come up with a reason that you should be that authority.
We're too old for clone wars, the only kid on the block that wants to play by its own rules is on another list, go patronize it ;)
The LFHS is the problem here, although putting applications where you want them in the filesystem would make Linux as hard to use as the Mac. Oh wait...
On Thu, Aug 02, 2007 at 07:47:02AM -0500, Les Mikesell wrote:
Axel Thimm wrote:
On Wed, Aug 01, 2007 at 11:29:25AM -0500, Les Mikesell wrote:
You'll have to remind me why anyone wants different same-named packages with differences the end user doesn't understand and can't control to exist at all before I can comment on a solution about managing them.
Let's assume no one wants that (I think I don't). Shouldn't you be chasing the repo that just created the duplicates instead of the ones that supported RHEL/CentOS over years now?
And before you rightfully extend the argument - as far as duplicates between RPMForge/Dag, Dries, Karan Extras, CentOS Extras SL contrib and ATrpms are concerned: We're working *together* on eliminating them.
And yet, conflicts have always kept popping up,
Really? Did you report them?
and I can't see any provision you make to enable additional repositories to exist
Just wait and see.
The LFHS is the problem here, although putting applications where you want them in the filesystem would make Linux as hard to use as the Mac. Oh wait...
IIRC you had some homework to do: Supply a dummy repo that doas all that you want and convince us thus that there is a problem this solution solves, so we can all follow your example. Go on and violate FHS, LSB and all their cousins, if your solution improves something these standard don't, we might all go for it. But until I see it I will respectfully assume that there is none (and will also not know what it was supposed to fix).
On Thu, 2007-08-02 at 07:47 -0500, Les Mikesell wrote:
Axel Thimm wrote:
On Wed, Aug 01, 2007 at 11:29:25AM -0500, Les Mikesell wrote:
You'll have to remind me why anyone wants different same-named packages with differences the end user doesn't understand and can't control to exist at all before I can comment on a solution about managing them.
Let's assume no one wants that (I think I don't). Shouldn't you be chasing the repo that just created the duplicates instead of the ones that supported RHEL/CentOS over years now?
And before you rightfully extend the argument - as far as duplicates between RPMForge/Dag, Dries, Karan Extras, CentOS Extras SL contrib and ATrpms are concerned: We're working *together* on eliminating them.
And yet, conflicts have always kept popping up, and I can't see any provision you make to enable additional repositories to exist without coordinating with your rules. The issue is that there is only one namespace which is the part that doesn't make sense and can't work without a single authority or a hierarchial structure, and I can't come up with a reason that you should be that authority.
We're too old for clone wars, the only kid on the block that wants to play by its own rules is on another list, go patronize it ;)
The LFHS is the problem here, although putting applications where you want them in the filesystem would make Linux as hard to use as the Mac. Oh wait...
That compromises one of GNU/Linux's biggest strengths, that of shared libraries. So instead of just upgrading OpenSSL, I now have to upgrade the following that is on one of my servers:
$ rpm -q --whatrequires libcrypto.so.4 cyrus-sasl-2.1.19-5.EL4 cyrus-sasl-md5-2.1.19-5.EL4 lftp-3.0.6-3 pyOpenSSL-0.6-1.p23 stunnel-4.05-3 wget-1.10.2-0.40E xmlsec1-openssl-1.2.6-3 libwvstreams-3.75.0-2 ipsec-tools-0.3.3-6.rhel4.1 bind-libs-9.2.4-24.EL4 bind-utils-9.2.4-24.EL4 bacula-client-2.0.3-1 openssl-0.9.7a-43.16 python-2.3.4-14.4 openldap-2.2.13-7.4E net-snmp-libs-5.1.2-11.EL4.10 postgresql-libs-7.4.17-1.RHEL4.1 net-snmp-5.1.2-11.EL4.10 cups-libs-1.1.22-0.rc1.9.20 curl-7.12.1-11.el4 net-snmp-utils-5.1.2-11.EL4.10 postgresql-server-7.4.17-1.RHEL4.1 OpenIPMI-1.4.14-1.4E.17 ntp-4.2.0.a.20040617-6.el4 openssh-server-3.9p1-8.RHEL4.20 openssh-clients-3.9p1-8.RHEL4.20 pam_ccreds-3-3.rhel4.2 openssh-3.9p1-8.RHEL4.20 postfix-2.2.10-1.1.el4 postgresql-7.4.17-1.RHEL4.1 dhcpv6_client-0.10-17_EL4 cups-1.1.22-0.rc1.9.20 $ rpm -q --whatrequires libssl.so.4 lftp-3.0.6-3 pyOpenSSL-0.6-1.p23 stunnel-4.05-3 wget-1.10.2-0.40E xmlsec1-openssl-1.2.6-3 libwvstreams-3.75.0-2 ipsec-tools-0.3.3-6.rhel4.1 bacula-client-2.0.3-1 openssl-0.9.7a-43.16 python-2.3.4-14.4 openldap-2.2.13-7.4E postgresql-libs-7.4.17-1.RHEL4.1 cups-libs-1.1.22-0.rc1.9.20 curl-7.12.1-11.el4 postgresql-server-7.4.17-1.RHEL4.1 postfix-2.2.10-1.1.el4 postgresql-7.4.17-1.RHEL4.1 cups-1.1.22-0.rc1.9.20
That's just awesome. The logistics of that is just staggering, imagine that just one maintainer failed to update code/recompile against fixed OpenSSL. However, I imagine that there could be a hybrid approach, but this is definitely /not/ the forum to be radically changing the way GNU/Linux behaves as a whole. A good start might be on the kernel devel list. HPFS also uses embedded meta info, that would probably be needed also. Essentially, you are talking *radical* changes when you start thinking along the lines of "Mac does this; Windows does that; Foo OS does some other thing...", some of which might be integrated /over time/.
Timothy Selivanow wrote:
The LFHS is the problem here, although putting applications where you want them in the filesystem would make Linux as hard to use as the Mac. Oh wait...
That compromises one of GNU/Linux's biggest strengths, that of shared libraries. So instead of just upgrading OpenSSL, I now have to upgrade the following that is on one of my servers:
Unixes have had mechanisms to handle multiple shared library versions probably for as long as shared libraries have existed. Are you sure you want _any_ enabled repository to be able to replace your stock ssl libs, though? So far the discussion has assumed that everyone involved is operating in good faith and all problems are just accidental, but what if...?
On Thu, 2007-08-02 at 13:26 -0500, Les Mikesell wrote:
Timothy Selivanow wrote:
The LFHS is the problem here, although putting applications where you want them in the filesystem would make Linux as hard to use as the Mac. Oh wait...
That compromises one of GNU/Linux's biggest strengths, that of shared libraries. So instead of just upgrading OpenSSL, I now have to upgrade the following that is on one of my servers:
Unixes have had mechanisms to handle multiple shared library versions probably for as long as shared libraries have existed.
Yes, but like alternatives, there is a default and each time you want to deviate from the default you must specify. Even implementing a meta filesystem to store per-application environment settings is just as much work in logistics as using wrapper-scripts. Not that it couldn't be done, but your are still talking about major changes that are beyond the scope of just RPM. You are looking for a quick and easy way (i.e., no real maintenance on your part) to have multiple libraries and multiple same programs with auto-magical negotiation that the under-laying structure doesn't support.
Are you sure you want _any_ enabled repository to be able to replace your stock ssl libs, though? So far the discussion has assumed that everyone involved is operating in good faith and all problems are just accidental, but what if...?
"What if" indeed! That is one reason why I use only /my/ repo on my servers. In the past I used Karan's for a few packages, but decided to just maintain a repo for the few extra packages I need. For desktop (F7), I use (currently) only one 3rd party repo (and well-known, so hopefully not shady in nature) and I am able to see what repo the updates are coming from in yumex and yum.
On Wed, 1 Aug 2007, Les Mikesell wrote:
Dag Wieers wrote:
I think you are making too much out of name differences for things that can clobber each other and not enough about ways to let the different things co-exist - on the same machines if you want them, or to let users choose which they want. If two same-named packages can conflict, someone did something wrong and the issue shouldn't be about who did it but how to avoid it.
I disagree. If I was going to roll my own packages in my own repository to overrule the OS repositories, tagging my packages would be essential.
But the tags are in an inconvenient position to control anything. How do you ensure that you'll get your copies if any other repo adds a newer release? Normally you'd want updates to float to the latest.
Correct, you would think Fedora took care of this, right ? But there is no interest for Fedora to take care of that because they want to be the only repository. It is not something they have an incentive for to fix.
That is exactly the problem. The repotag would be a workaround (and a convenient one for users) but the real changes need to be in yum or somewhere else. And Fedora does not care, so RHEL will not have it.
I have warned for this on the Feodra mailinglist years ago. There just is no interest to have the diversity of more than one repository.
From an end-user viewpoint, I can't see why anyone would want to maintain a potentially-conflicting package of something that can be freely distributed and keep it in an isolated repository, especially without any mechanism to control which will be installed.
Exactly, yum has a shortsighted implementation that does not allow control. Smart is much better at this and Smart-knowledge should be a requisite to enter this discussion.
A lot of people are brainwashed by the limits of a tool like yum. Smart is much better at allowing people to decide what they want.
Can you explain the reason anyone would want to have diversity instead of a single maintainer per package and the same packages in all repositories whose policies find them acceptable?
Because one user *wants* to have one version on their production server and only wants to update to a newer release when it is exactly the same version and only fixes bugs. (stability)
Another user wants to have the latest version on their test server to be able to test this latest release for acceptance. (current)
Both needs are perfectly understandable on an Enterprise Linux operating system, both could live in a single repository or on multiple repositories and people may want to define exactly what policy they want to follow, on a per repository bases or on a per package basis.
Smart does allow this !
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
--On Wednesday, August 01, 2007 5:04 PM +0200 Dag Wieers dag@wieers.com wrote:
For the kernel there is a lot of specialized logic to make it work.
Another example is Fedora's alternatives system (which, for example, allows multiple versions of Java to coexist) but again that requires specialized logic.
Kenneth Porter wrote:
--On Wednesday, August 01, 2007 5:04 PM +0200 Dag Wieers dag@wieers.com wrote:
For the kernel there is a lot of specialized logic to make it work.
Another example is Fedora's alternatives system (which, for example, allows multiple versions of Java to coexist) but again that requires specialized logic.
Question: how many levels of symlinks-pointing-to-symlinks does it take to get to the right place? And having supplied this number of symlinks, how can a user choose to execute one version of java while someone else prefers the other? Or how do you run one application under one version and another with a different one?
On Wed, 2007-08-01 at 16:02 -0500, Les Mikesell wrote:
Kenneth Porter wrote:
--On Wednesday, August 01, 2007 5:04 PM +0200 Dag Wieers dag@wieers.com wrote:
For the kernel there is a lot of specialized logic to make it work.
Another example is Fedora's alternatives system (which, for example, allows multiple versions of Java to coexist) but again that requires specialized logic.
Question: how many levels of symlinks-pointing-to-symlinks does it take to get to the right place? And having supplied this number of symlinks, how can a user choose to execute one version of java while someone else prefers the other? Or how do you run one application under one version and another with a different one?
There are several levels, just guessing off the top of my head, some might go through 5 or more. As far as choosing which one...the system gets one configured, the one that is /usr/bin/java (you can do a `/usr/sbin/alternatives --display java` to see what it is currently). For using all others, you have to explicitly tell it to use a specific java enviro.
For instance, something that you are familiar with: in tomcat4.conf, you can set JAVA_HOME="/usr/lib/jvm/java", and while you are installing OpenNMS, you do a `$OPENNMS_HOME/bin/runjava -s` which grabs JAVA_HOME from env, or `$OPENNMS_HOME/bin/runjava -S <path to JRE>` to set it explicitly and stores it in $OPENNMS_HOME/etc/java.conf.
The point is, you need to explicitly setup the environment /each time/, whether at command line or some other setting. Symlinks only provide a default. Yes, you can do what you have been wanting this entire thread: install things into a different directory tree so that you can have independent version running simultaneously. The trick is the environment needs to be set up each time in order for it to work.
The big problem with doing it with RPM, is that there is no central authority on who gets to put what where. Having a /usr/local/foo-repository/package1 and a /usr/local/bar-repository/package1 doesn't solve any of the problems that are described. Having customized directory structures only works on a case-by-case and as-needed basis, as they are not trivial, and there is really no way for a user (not admin) to be able to make those kinds of decisions. If you want a program compiled against different libraries, and have a user be able to access both, best way it to have it done in a custom fashion, building the environment using scripts if need be.
That all said, the best way to get repo mixing is probably just plain-old co-operation, and a bit of know-how.
Timothy Selivanow wrote:
Another example is Fedora's alternatives system (which, for example, allows multiple versions of Java to coexist) but again that requires specialized logic.
Question: how many levels of symlinks-pointing-to-symlinks does it take to get to the right place? And having supplied this number of symlinks, how can a user choose to execute one version of java while someone else prefers the other? Or how do you run one application under one version and another with a different one?
There are several levels, just guessing off the top of my head, some might go through 5 or more. As far as choosing which one...the system gets one configured, the one that is /usr/bin/java (you can do a `/usr/sbin/alternatives --display java` to see what it is currently). For using all others, you have to explicitly tell it to use a specific java enviro.
For instance, something that you are familiar with: in tomcat4.conf, you can set JAVA_HOME="/usr/lib/jvm/java",
Except, of course, that you have no reasonable way to know this location for the package(s) in question.
The point is, you need to explicitly setup the environment /each time/, whether at command line or some other setting.
Well, sort of. $HOME conveniently manages to be both unique and correct for different users at the same time and there are well-known ways to manage other personalized variables.
Symlinks only provide a default. Yes, you can do what you have been wanting this entire thread: install things into a different directory tree so that you can have independent version running simultaneously. The trick is the environment needs to be set up each time in order for it to work.
And that's not a difficult trick, given an OS where environment settings are always inherited from parent processes but you can change them when needed.
The big problem with doing it with RPM, is that there is no central authority on who gets to put what where. Having a /usr/local/foo-repository/package1 and a /usr/local/bar-repository/package1 doesn't solve any of the problems that are described. Having customized directory structures only works on a case-by-case and as-needed basis, as they are not trivial, and there is really no way for a user (not admin) to be able to make those kinds of decisions.
If they have different names a user can choose which he wants just like any other thing he chooses. Or if the user only knows how to click, different icons can do everything necessary.
If you want a program compiled against different libraries, and have a user be able to access both, best way it to have it done in a custom fashion, building the environment using scripts if need be.
Why? If there is a way that works in the custom case on one machine, it will work on another machine without duplicating the custom work.
That all said, the best way to get repo mixing is probably just plain-old co-operation, and a bit of know-how.
Perhaps someone who uses several jpackage packages can comment on how things are working out in FC6/7 and Centos5 where some small subset of things that look like jpackage packages have been included in the core repos? So far I don't see how this is going to work unless the whole mess is included. To simplify this, I understand how environment variables work and find them very predictable. I can't predict what two different repositories are going to contain tomorrow and don't ever expect to be able to. I'd rather trust my luck to the thing I can control.
On Wed, 2007-08-01 at 18:23 -0500, Les Mikesell wrote:
Timothy Selivanow wrote:
Another example is Fedora's alternatives system (which, for example, allows multiple versions of Java to coexist) but again that requires specialized logic.
Question: how many levels of symlinks-pointing-to-symlinks does it take to get to the right place? And having supplied this number of symlinks, how can a user choose to execute one version of java while someone else prefers the other? Or how do you run one application under one version and another with a different one?
There are several levels, just guessing off the top of my head, some might go through 5 or more. As far as choosing which one...the system gets one configured, the one that is /usr/bin/java (you can do a `/usr/sbin/alternatives --display java` to see what it is currently). For using all others, you have to explicitly tell it to use a specific java enviro.
For instance, something that you are familiar with: in tomcat4.conf, you can set JAVA_HOME="/usr/lib/jvm/java",
Except, of course, that you have no reasonable way to know this location for the package(s) in question.
The point is, you need to explicitly setup the environment /each time/, whether at command line or some other setting.
Well, sort of. $HOME conveniently manages to be both unique and correct for different users at the same time and there are well-known ways to manage other personalized variables.
Yes. That's env magic.
Symlinks only provide a default. Yes, you can do what you have been wanting this entire thread: install things into a different directory tree so that you can have independent version running simultaneously. The trick is the environment needs to be set up each time in order for it to work.
And that's not a difficult trick, given an OS where environment settings are always inherited from parent processes but you can change them when needed.
MacOS X is known for an ability similar to that. It's called static building. Otherwise, GNU/Linux does exactly that, inherits the env from parent unless over ridden. You can do that by making wrapper-scripts.
The big problem with doing it with RPM, is that there is no central authority on who gets to put what where. Having a /usr/local/foo-repository/package1 and a /usr/local/bar-repository/package1 doesn't solve any of the problems that are described. Having customized directory structures only works on a case-by-case and as-needed basis, as they are not trivial, and there is really no way for a user (not admin) to be able to make those kinds of decisions.
If they have different names a user can choose which he wants just like any other thing he chooses. Or if the user only knows how to click, different icons can do everything necessary.
If you strip the rant away, that's pretty much what I was trying to get at if you include the below paragraph.
If you want a program compiled against different libraries, and have a user be able to access both, best way it to have it done in a custom fashion, building the environment using scripts if need be.
Why? If there is a way that works in the custom case on one machine, it will work on another machine without duplicating the custom work.
There is a way. Make a custom RPM, or even an advanced script (ala gentoo ebuild system). That isn't the problem, it's the name space. There is no guarantee that what ever you choose it going to be unique and therefore not over-written by someone else. How do you think Red Hat does the dual arch libs in x86_64? That was dictated though, and everyone follows it.
That all said, the best way to get repo mixing is probably just plain-old co-operation, and a bit of know-how.
Perhaps someone who uses several jpackage packages can comment on how things are working out in FC6/7 and Centos5 where some small subset of things that look like jpackage packages have been included in the core repos? So far I don't see how this is going to work unless the whole mess is included. To simplify this, I understand how environment variables work and find them very predictable. I can't predict what two different repositories are going to contain tomorrow and don't ever expect to be able to. I'd rather trust my luck to the thing I can control.
So far, the reason why it's working is that Red Hat employees and volunteers also do packages and bug-fixes for JPackage, and it doesn't work all the time (I also subscribe to JPackage lists). Excerpt below:
--snip-- On Tue, 2007-07-31 at 08:36 -0700, David Fischer (DHL US) wrote:
Is there a FAQ on what packages from the fedora side and jpackage side can be used together?
I know I have asked this in the past but it is getting really hard to
do
a JPackage only fedora when all the version numbers are screwed up.
Can
you use JPackage and Fedora packages together with out any problems??
or
do I have to stay in this hell???
This is a little Fedora centric so not 100% sure if this is the ideal location to ask this, anyway, there is a packaging policy in place: http://fedoraproject.org/wiki/Packaging/JPackagePolicy that is being adhered to at least since F-7 meant exactly to avoid this problem. If you find that fedora packages are violating this policy then please open bugs against them.
Thanks, Vivek --snip--
If you read the packaging policy, it says that it is the *only* case where they are allowing repotags. That doesn't even solve the collision problem, and can even obscure it in some cases.
--On Wednesday, August 01, 2007 4:40 PM -0700 Timothy Selivanow timothys@easystreet.com wrote:
There is a way. Make a custom RPM, or even an advanced script (ala gentoo ebuild system). That isn't the problem, it's the name space. There is no guarantee that what ever you choose it going to be unique and therefore not over-written by someone else. How do you think Red Hat does the dual arch libs in x86_64? That was dictated though, and everyone follows it.
What ever happened to putting all non-distro stuff in /opt/vendor/application? And referring to any binaries in there by abolute path, instead of depending on dumping all binaries in /usr/bin. At least for stuff not invoked by hand from a console, that should be workable. System services and stuff invoked from icons could and probably should use absolute paths.
(I'm not proposing this. I'm asking why it's not the norm.)
We would then have /opt/RPMforge and /opt/EPEL and all their respective packages would drop into separate trees.
Kenneth Porter napsal(a):
--On Wednesday, August 01, 2007 4:40 PM -0700 Timothy Selivanow timothys@easystreet.com wrote:
There is a way. Make a custom RPM, or even an advanced script (ala gentoo ebuild system). That isn't the problem, it's the name space. There is no guarantee that what ever you choose it going to be unique and therefore not over-written by someone else. How do you think Red Hat does the dual arch libs in x86_64? That was dictated though, and everyone follows it.
What ever happened to putting all non-distro stuff in /opt/vendor/application? And referring to any binaries in there by abolute path, instead of depending on dumping all binaries in /usr/bin. At least for stuff not invoked by hand from a console, that should be workable. System services and stuff invoked from icons could and probably should use absolute paths.
(I'm not proposing this. I'm asking why it's not the norm.)
We would then have /opt/RPMforge and /opt/EPEL and all their respective packages would drop into separate trees.
it is bad that it is not norm ... ;-)
Form my point of view (FMPOV) is placing everithing to /usr/bin bad too over there FMPOV everithing what is not core system should by in /usr/local/bin or bigger packages in /opt
Question is what is part of core system? Xorg server YES ???? Gnome NO ????
--On Thursday, August 02, 2007 9:33 AM +0200 ""Petr \"Qaxi\" Klíma"" qaxi@seznam.cz wrote:
Form my point of view (FMPOV) is placing everithing to /usr/bin bad too over there FMPOV everithing what is not core system should by in /usr/local/bin or bigger packages in /opt
/usr/local is for the local administrator, not for packages. Stuff like backup scripts and stuff built outside of packages. /opt is for 3rd party vendors, so it seems a reasonable place to put 3rd party repo stuff.
On Wed, Aug 01, 2007 at 04:02:08PM -0500, Les Mikesell wrote:
Question: how many levels of symlinks-pointing-to-symlinks does it take to get to the right place? And having supplied this number of symlinks, how can a user choose to execute one version of java while someone else prefers the other? Or how do you run one application under one version and another with a different one?
The question you have asked is a _complicated_ one. Many businesses have come up with home grown solutions to this problem (in my place it's called DAM; Dynamic Application Management; default values are determined by individual/group/server/NIS). It works on Solaris, HPUX, AIX and Linux.
However, it's _definitely_ beyond the scope of an OS package management system such as yum and rpm.
Anyone who wants to run more than one version of a specific piece of software is a "power user" (whether they recognise it or not) and the standard pre-built RPMs found in the repositories are _not_ designed for them. Such a user should build their own versions or use a repository designed for multi-versioning.
You have to recognise the limited problem that the repositories were meant to solve. They're not meant to be the ultimate answer to everyone's problems; they're meant to be a simple collection of software then typical end user can make use of. repotags would help avoid conflicts between repositories.
They are _not_ meant to solve the multi-versioning issue.
Kludges such as "alternatives" is a true kludge requiring the rpm packages to support it (ie a build time issue) and is not a solution to handling multiple repos nor multiple versions as a generic solution.
Stephen Harris wrote:
On Wed, Aug 01, 2007 at 04:02:08PM -0500, Les Mikesell wrote:
Question: how many levels of symlinks-pointing-to-symlinks does it take to get to the right place? And having supplied this number of symlinks, how can a user choose to execute one version of java while someone else prefers the other? Or how do you run one application under one version and another with a different one?
The question you have asked is a _complicated_ one. Many businesses have come up with home grown solutions to this problem (in my place it's called DAM; Dynamic Application Management; default values are determined by individual/group/server/NIS). It works on Solaris, HPUX, AIX and Linux.
However, it's _definitely_ beyond the scope of an OS package management system such as yum and rpm.
I could have sworn that when I had yum working right with the jpackage repos I was able to: yum install tomcat4 yum install tomcat5 yum install tomcat55 and then run whichever I wanted with the appropriate service tomcatx start and if I had modified the config files to listen on different ports I probably could have started them all at once. Didn't seem that complicated when the packagers understand the concept. But now I don't see jpackage repos for centos5 so I don't know how it will mesh with parts packaged in the base repos with a one size fits all mentality.
Anyone who wants to run more than one version of a specific piece of software is a "power user" (whether they recognise it or not)
More likely they are just trying to cope with components from different places that each require specific versions of other things to work at all. A real power user would modify it all to work with the latest of everything...
and the standard pre-built RPMs found in the repositories are _not_ designed for them.
And that's the problem. I suppose the current solution is to treat it like Windows DLL-Hell and only run one program per machine - or emulate that solution with virtual machines whose only purpose is to let you have some different versioned library that is packaged in a way it can't coexist with anything else. This just seems unfortunate for an OS designed long ago to deal with multiple version concepts at all the necessary levels.
Such a user should build their own versions or use a repository designed for multi-versioning.
Jpackage seems to be the only one.
You have to recognise the limited problem that the repositories were meant to solve. They're not meant to be the ultimate answer to everyone's problems; they're meant to be a simple collection of software then typical end user can make use of. repotags would help avoid conflicts between repositories.
They are _not_ meant to solve the multi-versioning issue.
They don't prevent it if the packagers understand it. We really shouldn't need a thousand different linux distributions each with their own dozen versions and hundreds of updates to sort through to find the combination you need this week.
Kludges such as "alternatives" is a true kludge requiring the rpm packages to support it (ie a build time issue) and is not a solution to handling multiple repos nor multiple versions as a generic solution.
At least we agree on something.
On Wed, Aug 01, 2007 at 10:34:17PM -0500, Les Mikesell wrote:
Stephen Harris wrote:
On Wed, Aug 01, 2007 at 04:02:08PM -0500, Les Mikesell wrote:
Question: how many levels of symlinks-pointing-to-symlinks does it take to get to the right place? And having supplied this number of symlinks, how can a user choose to execute one version of java while someone else prefers the other? Or how do you run one application under one version and another with a different one?
The question you have asked is a _complicated_ one. Many businesses have come up with home grown solutions to this problem (in my place it's called DAM; Dynamic Application Management; default values are determined by individual/group/server/NIS). It works on Solaris, HPUX, AIX and Linux.
However, it's _definitely_ beyond the scope of an OS package management system such as yum and rpm.
I could have sworn that when I had yum working right with the jpackage repos I was able to: yum install tomcat4 yum install tomcat5 yum install tomcat55
That's barely touching the surface of this complicated mess. What if I want tomcat4.0.1 and tomcat4.0.2? perl5.8.0 and perl5.8.1 and perl5.8.2 ? If these all go into their own directory trees then the user will _never_ know where to find perl ("/usr/bin/perl" would be a conflict that needs managing).
Now what happens if Fred creates a tin1.8.2 and John creates a tin1.8.2 but with different compile options? If we can't even get all the repostories to use a simple repotag, we'd never get them to compile with non-standard paths!
Stephen Harris wrote:
Now what happens if Fred creates a tin1.8.2 and John creates a tin1.8.2 but with different compile options?
That's really not a big problem and anyone who does development on a multiuser machine will be doing it all the time. In fact even a single developer will likely have different versions compiled for testing at the same time. The problem arises when someone has to decide which, if any, should become the 'standard' version, at which point it becomes an issue of authority, not a technical problem.
If we can't even get all the repostories to use a simple repotag, we'd never get them to compile with non-standard paths!
If everyone is going to fight over the same space it again becomes a matter of authority - or a free-for-all.
If we can't even get all the repostories to use a simple repotag, we'd never get them to compile with non-standard paths!
If everyone is going to fight over the same space it again becomes a matter of authority - or a free-for-all.
So adding a tag to indicate where the claim comes from so that the end user gets to decide who gets to have their claim validated is a fight for authority as opposed to those who flatly refuse to have to claim and just want the end user to use their repo only?
Les Mikesell wrote:
Feizhou wrote:
Les Mikesell wrote:
Dag Wieers wrote:
You may argue that that is a good thing. But Fedora is a different beast than RHEL. People may want stable packages, or current packages and a single repository (with the tools we have today) cannot provide this.
But people may want _both_ the stable package and the current package on the same machine at the same time. Having a hint of the difference barely visible in the package name doesn't help a bit.
I cannot see how it is possible to install both the stable package and current package.
How many kernel packages do you have installed? All it takes is to not write the same-named file in the same place as the other package. In some cases there are practical problems where a service needs to listen on a default port and you can't run 2 at once, or the init script is expected to live in a certain place so we'd need a creative solution, but most files could just have their own unique path and you'd pick the one you want with your PATH setting - something well understood decades ago.
ROTFL. Have you ever noticed that the kernel packages all contain files that have different names from other packages?
Besides the kernel packages, none of the others do.
Besides, it punishes people who did not have an alternative back when Fedora Extras refused to do RHEL packages and only had RPMforge to fall back on.
At least that's my point of view.
I think you are making too much out of name differences for things that can clobber each other and not enough about ways to let the different things co-exist - on the same machines if you want them, or to let users choose which they want. If two same-named packages can conflict, someone did something wrong and the issue shouldn't be about who did it but how to avoid it.
I disagree. If I was going to roll my own packages in my own repository to overrule the OS repositories, tagging my packages would be essential.
But the tags are in an inconvenient position to control anything. How do you ensure that you'll get your copies if any other repo adds a newer release? Normally you'd want updates to float to the latest.
I will very well shut out similarly named packages in other third-party repos in the yum configuration.
On Tue, Jul 31, 2007 at 10:17:00PM -0500, Les Mikesell wrote:
Dag Wieers wrote:
You may argue that that is a good thing. But Fedora is a different beast than RHEL. People may want stable packages, or current packages and a single repository (with the tools we have today) cannot provide this.
But people may want _both_ the stable package and the current package on the same machine at the same time. Having a hint of the difference barely visible in the package name doesn't help a bit.
Besides, it punishes people who did not have an alternative back when Fedora Extras refused to do RHEL packages and only had RPMforge to fall back on.
At least that's my point of view.
I think you are making too much out of name differences for things that can clobber each other and not enough about ways to let the different things co-exist - on the same machines if you want them, or to let users choose which they want. If two same-named packages can conflict, someone did something wrong and the issue shouldn't be about who did it but how to avoid it.
I pretend I bite. How are two libfoos going to coexist? Or two perl modules? Or two python modules? Or two ...
Actually there are ways, but once you sketch them you'll find the cure far worse than the asserted disease. So your homework is to setup a dummy repo that works that way. You will either find the perfect solution and we'll all bow in front of you, or you will cry for apologies. ;)
Okay folks, I think we've just about beaten this horse long enough. Lets all agree that the whole mess needs some clarity, and that any griping on this list is not likely to resolve the issue.
Can we please let this thread die now and get back to some centos related help/business?
--- Jim Perrin jperrin@gmail.com wrote:
Okay folks, I think we've just about beaten this horse long enough. Lets all agree that the whole mess needs some clarity, and that any griping on this list is not likely to resolve the issue.
Can we please let this thread die now and get back to some centos related help/business?
-- During times of universal deceit, telling the truth becomes a revolutionary act. George Orwell _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Willlbur :)
Steven
Get your Art Supplies @ www.littleartstore.com
-
"Petr \"Qaxi\" Klíma" -
Axel Thimm -
Dag Wieers -
drew einhorn -
Feizhou -
JC Júnior -
Jim Perrin -
Johnny Hughes -
Kenneth Porter -
Les Mikesell -
R P Herrold -
Ralph Angenendt -
Ray Van Dolson -
Rex Dieter -
Stephen Harris -
Stephen John Smoogen -
Steven Vishoot -
Timothy Selivanow