Hello everyone Does anyone know of a definitive compatibility list for yum? There are more and more different repos all over the place, some warning not to mix with repo xyz - this can get confusing and trying to keep a stable, up to date box! Could someone point me to a list? or if there are a lot of replies to this, I could make one. Thanks
On Wed, 2004-11-03 at 10:46 +0000, Elvis wrote:
Hello everyone Does anyone know of a definitive compatibility list for yum? There are more and more different repos all over the place, some warning not to mix with repo xyz - this can get confusing and trying to keep a stable, up to date box! Could someone point me to a list? or if there are a lot of replies to this, I could make one.
No list, but this is definitely a FAQ
Compatible (definitely, w/assurance):
Fedora.us Livna Jpackage Macromedia Flash (possibly, a little unsure here) Freshrpms
Not-compatible with the above (but maybe with each other): Dag apt.sw.be atrpms (if above fails :P) Freshrpms Nyquist <insert joe random repo>
This all for x86. I understand that Livna has stopped building x86_64 packages, and fedora.us never automated builds for these either
Hang in there, as Fedora Extras will be launched sooner than you know (or not :P), and that would mean clearer definitions of these repos/etc...
On Thu, 4 Nov 2004, Colin Charles wrote:
On Wed, 2004-11-03 at 10:46 +0000, Elvis wrote:
Hello everyone Does anyone know of a definitive compatibility list for yum? There are more and more different repos all over the place, some warning not to mix with repo xyz - this can get confusing and trying to keep a stable, up to date box! Could someone point me to a list? or if there are a lot of replies to this, I could make one.
No list, but this is definitely a FAQ
Compatible (definitely, w/assurance):
Fedora.us Livna Jpackage Macromedia Flash (possibly, a little unsure here) Freshrpms
Not-compatible with the above (but maybe with each other): Dag apt.sw.be atrpms (if above fails :P) Freshrpms Nyquist
<insert joe random repo>
Let me add to this that the incompatability of the 3rd party repositories has nothing to do with the inability or unwillingness of the 3rd party packagers (to the contrary). But the unwillingness (and policy) of fedora.us to not allow for compatibility. Apparently it is too hard to work with the community.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
Torsdag 04 november 2004 19:40 skrev Dag Wieers:
Let me add to this that the incompatability of the 3rd party repositories has nothing to do with the inability or unwillingness of the 3rd party packagers (to the contrary). But the unwillingness (and policy) of fedora.us to not allow for compatibility. Apparently it is too hard to work with the community.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ --
That is really interesting. I use
rpm http://apt.sw.be fedora/2/en/i386 dag from your repository rpm http://ayo.freshrpms.net fedora/linux/2/i386 core updates freshrpms from freshrpms and
rpm ftp://apt.us.kde-redhat.org/linux/kde-redhat/apt/ fedora/2 stable rpm ftp://apt.us.kde-redhat.org/linux/kde-redhat/apt/ fedora/all stable rpm ftp://apt.us.kde-redhat.org/linux/kde-redhat/apt/ kde-redhat/2 stable rpm ftp://apt.us.kde-redhat.org/linux/kde-redhat/apt/ kde-redhat/all stable
from kde-redhat. Unitl recently I had no problems, but the last couple of days a little bit. I have normally gotten mplayer from freshrpms, but recently there was an upgrade from your repository. Is that problem free
Erik
On Thu, 4 Nov 2004, Erik Kjær Pedersen wrote:
Torsdag 04 november 2004 19:40 skrev Dag Wieers:
Let me add to this that the incompatability of the 3rd party repositories has nothing to do with the inability or unwillingness of the 3rd party packagers (to the contrary). But the unwillingness (and policy) of fedora.us to not allow for compatibility. Apparently it is too hard to work with the community.
That is really interesting. I use
rpm http://apt.sw.be fedora/2/en/i386 dag from your repository rpm http://ayo.freshrpms.net fedora/linux/2/i386 core updates freshrpms from freshrpms and
rpm ftp://apt.us.kde-redhat.org/linux/kde-redhat/apt/ fedora/2 stable rpm ftp://apt.us.kde-redhat.org/linux/kde-redhat/apt/ fedora/all stable rpm ftp://apt.us.kde-redhat.org/linux/kde-redhat/apt/ kde-redhat/2 stable rpm ftp://apt.us.kde-redhat.org/linux/kde-redhat/apt/ kde-redhat/all stable
from kde-redhat. Unitl recently I had no problems, but the last couple of days a little bit. I have normally gotten mplayer from freshrpms, but recently there was an upgrade from your repository. Is that problem free
If you find a compatibility problem, you should file a bug. Probably the best place to report it is the freshrpms mailinglist:
freshrpms-list@freshrpms.net
We're all committed to resolving incompatibilities as fast as we can and we're looking at ways to prevent (or detect) incompatibilities before they matter. Having said that, incompatibilities do not occur that often, unless you're using fedora.us/livna.org unfortunately. The reason is explained in some of the mails in this thread.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
Fredag 05 november 2004 10:14 skrev Dag Wieers:
If you find a compatibility problem, you should file a bug. Probably the best place to report it is the freshrpms mailinglist:
As it turns out I did not have a problem, it was only a non responding mirror as you so kindly pointed out to me. I am sorry you have to deal with idiots like this :-)
Erik
On Fri, 5 Nov 2004, Erik Kjær Pedersen wrote:
Fredag 05 november 2004 10:14 skrev Dag Wieers:
If you find a compatibility problem, you should file a bug. Probably the best place to report it is the freshrpms mailinglist:
As it turns out I did not have a problem, it was only a non responding mirror as you so kindly pointed out to me. I am sorry you have to deal with idiots like this :-)
Well, your concern is a valid one. I should look into a more robust way of synchronizing that would prevent this. If it happens it usually is for a small time though.
On the other side, I believe Yum and apt should better handle situations where packages are missing. Often they bail out and loudly complain of something broken. If I was an enduser I would seriously doubt either the software or the infrastructure. A missing package is not necessarily a reason to break or to shout. It should be reported, sure, but it should not cause much grieve.
The reason that these situations are frustrating for end-users is because if something like that occurs and Yum or Apt won't work beyond that they're stuck. And you stare at the blinking prompt and wonder what to do with your time now that yum or apt does not work :)))
PS As a repository maintainer I would love to be able to remove packages from a repository without necessarily needing to update the repository metadata right away. It would give me more flexibility to act quickly when necessary.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On Fri, 2004-11-05 at 01:40 +0100, Dag Wieers wrote:
On Thu, 4 Nov 2004, Colin Charles wrote:
On Wed, 2004-11-03 at 10:46 +0000, Elvis wrote:
Hello everyone Does anyone know of a definitive compatibility list for yum? There are more and more different repos all over the place, some warning not to mix with repo xyz - this can get confusing and trying to keep a stable, up to date box! Could someone point me to a list? or if there are a lot of replies to this, I could make one.
No list, but this is definitely a FAQ
Compatible (definitely, w/assurance):
Fedora.us Livna Jpackage Macromedia Flash (possibly, a little unsure here) Freshrpms
Not-compatible with the above (but maybe with each other): Dag apt.sw.be atrpms (if above fails :P) Freshrpms Nyquist
<insert joe random repo>
Let me add to this that the incompatability of the 3rd party repositories has nothing to do with the inability or unwillingness of the 3rd party packagers (to the contrary). But the unwillingness (and policy) of fedora.us to not allow for compatibility. Apparently it is too hard to work with the community.
And if this is making the FAQ, it should be made clear that:
Dag, newrpms, atrpms, freshrpms are fully compatible with each other (info from http://freshrpms.net/links)
Fedora.us, livna, jpackage, flash is yet another compatible lot
Don't forget to add a link to http://www.fedora.us/wiki/RepositoryMixingProblems
And alas, Dag, and the rest of the repos, I'm sure there's light at the end of the tunnel and if we all forget our differences just for a bit, the Extras thing will be a bigger, greater, reality (no point inter-repo-"fighting", when our goal is to have a great number of packages, when we can truly say, "we package the universe")
Warmest regards
On Fri, 5 Nov 2004, Colin Charles wrote:
On Fri, 2004-11-05 at 01:40 +0100, Dag Wieers wrote:
On Thu, 4 Nov 2004, Colin Charles wrote:
On Wed, 2004-11-03 at 10:46 +0000, Elvis wrote:
Hello everyone Does anyone know of a definitive compatibility list for yum? There are more and more different repos all over the place, some warning not to mix with repo xyz - this can get confusing and trying to keep a stable, up to date box! Could someone point me to a list? or if there are a lot of replies to this, I could make one.
No list, but this is definitely a FAQ
Let me add to this that the incompatability of the 3rd party repositories has nothing to do with the inability or unwillingness of the 3rd party packagers (to the contrary). But the unwillingness (and policy) of fedora.us to not allow for compatibility. Apparently it is too hard to work with the community.
And if this is making the FAQ, it should be made clear that:
Dag, newrpms, atrpms, freshrpms are fully compatible with each other (info from http://freshrpms.net/links)
Please add planetccrma, dries, biorpms, jpackage, pyvault, spc, kde-redhat, monkeyrpms and flash to that lot.
Fedora.us, livna, jpackage, flash is yet another compatible lot
Don't forget to add a link to http://www.fedora.us/wiki/RepositoryMixingProblems
And alas, Dag, and the rest of the repos, I'm sure there's light at the end of the tunnel and if we all forget our differences just for a bit, the Extras thing will be a bigger, greater, reality (no point inter-repo-"fighting", when our goal is to have a great number of packages, when we can truly say, "we package the universe")
Let us know when you're ready :)
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On Fri, 05 Nov 2004 12:48:12 +1100, Colin Charles wrote:
Don't forget to add a link to http://www.fedora.us/wiki/RepositoryMixingProblems
That page also explains why fedora.us cannot guarantee compatibility with other repositories, quoted below for completeness and as food for discussion. The paragraph is unchanged since April 25th, 2003.
The Fedora.us project has made a decision that we cannot guarantee compatibility with other repositories because it is unmaintainable for these reasons:
* The only way to avoid package conflicts when using multiple repositories is to completely avoid publishing packages that somebody else packages. This is obviously not an option because it would be too limiting for the Fedora project.
* Coordination among two or more repositories for compatibility would be far too difficult and incur much greater overhead. Updates would often involve multiple repository owners working in coordinated development and simultaneous publishing in order to prevent user breakage. This is a huge amount of extra development overhead.
* Users may also have any arbitrary mix of repositories, creating an unsupportable testing nightmare.
For anyone, who seeks for comments from fedora.us leadership, fedora-devel-list might be much more suitable.
Fredag 05 november 2004 09:07 skrev Michael Schwendt:
The only way to avoid package conflicts when using multiple repositories is to completely avoid publishing packages that somebody else packages. This is obviously not an option because it would be too limiting for the Fedora project.
The problem is that only using the rpms on the fedora.us site is too limiting for my computer
On Fri, 5 Nov 2004, Michael Schwendt wrote:
On Fri, 05 Nov 2004 12:48:12 +1100, Colin Charles wrote:
Don't forget to add a link to http://www.fedora.us/wiki/RepositoryMixingProblems
That page also explains why fedora.us cannot guarantee compatibility with other repositories, quoted below for completeness and as food for discussion. The paragraph is unchanged since April 25th, 2003.
The Fedora.us project has made a decision that we cannot guarantee compatibility with other repositories because it is unmaintainable for these reasons: * The only way to avoid package conflicts when using multiple repositories is to completely avoid publishing packages that somebody else packages. This is obviously not an option because it would be too limiting for the Fedora project.
Since fedora.us started without any packages and there were already a number of existing repositories with a good amount of packages. The fedora.us policy could have been to work together with existing repositories and implement something that could have worked.
You don't have to "avoid publishing packages that somebody else packages". You could have worked together with existing packagers to offer the same packages. This is one way of doing it, there are others that could have worked.
With RPMforge this is what our goal is, merge all the SPEC files, take the best of what we have, allow multiple packagers to work together on the single SPEC file, make this SPEC file work for multiple distributions (fedora, red hat, yellow dog, aurora, caos) and for multiple architectures (i386, x86_64, alpha, ppc, sparc) and allow people to publish the same packages that result from the same SPEC files.
And we have some new ideas being implemented to allow to build (cross distribution) communities around specific set of packages. This is not limited to only Fedora and only i386 and we operate with fewer people than fedora.us, which is something that we hope to address too if we have the proper tools for that.
No conflicts, complete compatibility and cooperation. This is what fedora.us could have done, but they decided to take another path. That's fine with me, but that's why there are now 2 different camps and that's why I think the FAQ has a very limited and twisted scope.
And I think that page is the main reason why there never has been a debate what would be best. It prohibited it.
* Coordination among two or more repositories for compatibility would be far too difficult and incur much greater overhead. Updates would often involve multiple repository owners working in coordinated development and simultaneous publishing in order to prevent user breakage. This is a huge amount of extra development overhead.
Isn't that what Open Source is about ? Besides why would there be more overhead than say having 5 people work on a SPEC file using bugzilla. You have to agree on things too and work on policies and procedures. If you avoid any of that, you avoid the most important questions that you should ask as a group of packagers.
I think the paragraph exagerates the overhead, but of course as a newcomer fedora.us would have had to worked with others which is harder than executing your own plan. If you look at the limited resources we have and what we've achieved in less than 2 years time I don't think the overhead you mentioned is hardly a valid argument.
* Users may also have any arbitrary mix of repositories, creating an unsupportable testing nightmare.
Which is only true if you have 5 SPEC files resulting in 5 packages, as I said there are other ways to reach the same goal and we've opted to have a single SPEC file resulting (if necessary) into 5 packages. The next step obviously is to look at why we still need 5 packages and how to merge the lot.
But working together means you have to agree before taking a next step, and you can't take big steps in one time. I'm sure fedora.us, now that it has packages and is maturing, is working at a slower pace than at the beginning. You can't just change direction anymore if you have a large userbase.
For anyone, who seeks for comments from fedora.us leadership, fedora-devel-list might be much more suitable.
I'm no longer seeking comments from fedora.us leadership :) I'm just hoping some of my rhetoric rings a bell and may change things for the better.
I'm interested to hear other's opinion about it, the answer may come from an outsider.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On Fri, 2004-11-05 at 08:05, Dag Wieers wrote:
For anyone, who seeks for comments from fedora.us leadership, fedora-devel-list might be much more suitable.
I'm no longer seeking comments from fedora.us leadership :) I'm just hoping some of my rhetoric rings a bell and may change things for the better.
I'm interested to hear other's opinion about it, the answer may come from an outsider.
---- from an interested party on the sidelines...
I see some extremely talented people - Michael Schwendt, Dag Wieers and Axel Thimm not working together and I am disappointed. I certainly credit of them (and others of course) for their tireless efforts, their good intentions and extremely valuable contributions.
The problem with incompatible repositories raises the complexity for those of us that aren't necessarily equipped to deal with them and it creates unnecessary FUD.
My appeal would be a Rodney King like - "can't we all get along?" but if this has to be a competition of philosophies, I can't forget how great it was to take an old RH 8.0 machine, install apt, change the repository to Axel's and apt-get dist upgrade to Fedora and then apt-get install mythtv-suite.
It's clear to me that some compromise is eventually the only way, it's really a question of when. It would be nice to see it happen for FC-3 releases.
Craig
On Fri, 5 Nov 2004 16:05:00 +0100 (CET), Dag Wieers wrote:
That page also explains why fedora.us cannot guarantee compatibility with other repositories, quoted below for completeness and as food for discussion. The paragraph is unchanged since April 25th, 2003.
Since fedora.us started without any packages and there were already a number of existing repositories with a good amount of packages. The fedora.us policy could have been to work together with existing repositories and implement something that could have worked.
Sorry that I won't participate in going back to very old threads from fedora-devel@fedora.us list, which were not fruitful. It's beyond my time. The list archives are still open. Everybody is free to skim over the several hundred relevant messages and look at the problem. Okay, I added my comments in this thread, but that's just because I'm subscribed to this list.
There are a very few people (or maybe it's just one) who don't realize that I'm just a contributor. I'm not in charge of the policies and objectives. I'm not a fedora.us spokesman either. Gah! It's insane to think that, when I never ever claimed to be a spokesman. Fedora.us provides a system which allows community commitment, where I, as a member of the community, can contribute. Other contributors have noticed the possibility, too. On the contrary, when fedora.us was started, and even many months later, no other packaging project was ready to accept community commitment beyond private mails or mailing-lists.
An environment, where competition between repositories dominates and crushes any attempts at working towards a higher common goal, is hostile instead of beneficial. Do we all have the same goal with extra packages? No, we don't. Not even with common libraries, I've been told. I understand that e.g. Matthias Saou didn't want to "give up" freshrpms.net in favour of maintaining his packages as part of a project that started as "Fedora Linux". But as could be read on the old fedora-devel list, the other contributors did not see a way to base their project on packages from an external repository, packages which are out of their control.
* Users may also have any arbitrary mix of repositories, creating an unsupportable testing nightmare.Which is only true if you have 5 SPEC files resulting in 5 packages, as I said there are other ways to reach the same goal and we've opted to have a single SPEC file resulting (if necessary) into 5 packages. The next step obviously is to look at why we still need 5 packages and how to merge the lot.
Why not take the route of Fedora Extras and extend Fedora Core with add-on packages, which to use as foundation for even more packages? A single easy-to-find place where to get extra packages instead of a multitude of repositories around the world. A single repository which CD manufacturers can mirror and burn onto CD/DVD. A single repository which to include and support directly from within Fedora Core. Why have many 3rd party repositories, which first extend Fedora Core and then extend eachother? Why not create Fedora Extras and then add complementry, special purpose 3rd party repositories, which depend on it?
I'm sure fedora.us, now that it has packages and is maturing, is working at a slower pace than at the beginning. You can't just change direction anymore if you have a large userbase.
IMHO, the situation hasn't changed at all. The total number of package developers has increased. There are still new submissions added to the package requests queue. But the general willingness to adhere to the policies/guidelines and make _utilisable contributions_ (reviews, approvals, packages which don't fail to build) is still missing. The interest in getting packages accepted and included is there. But the willingness to team up with other developers is missing.
Fredag 05 november 2004 11:04 skrev Michael Schwendt:
Why not take the route of Fedora Extras and extend Fedora Core with add-on packages, which to use as foundation for even more packages? A single easy-to-find place where to get extra packages instead of a multitude of repositories around the world.
It would be terible if that should happen. I use the rpm's from kde-redhat, and they are just so much better than the ones from the fedora project. I know because at work we have a standard fedora installation. I also really like various rpm's I get from freshrpms and from dags repository, but the example of kde-redhat where the rpm's exist in fedora.us shows that sometimes the willingness do them the best possible way is apparently not there.
Erik
On Fri, 5 Nov 2004 11:34:03 -0500, Erik Kjær Pedersen wrote:
Why not take the route of Fedora Extras and extend Fedora Core with add-on packages, which to use as foundation for even more packages? A single easy-to-find place where to get extra packages instead of a multitude of repositories around the world.
It would be terible if that should happen. I use the rpm's from kde-redhat, and they are just so much better than the ones from the fedora project.
Apples and oranges.
The kde-redhat project doesn't fit into the Fedora Extras definition, because it replaces packages in Fedora Core. That makes it either a Fedora Alternatives style repository or a 3rd party repository with even more freedom.
Working on Fedora Extras as an extended collection of packages doesn't terminate kde-redhat's right to exist.
know because at work we have a standard fedora installation. I also really like various rpm's I get from freshrpms and from dags repository, but the example of kde-redhat where the rpm's exist in fedora.us shows that sometimes the willingness do them the best possible way is apparently not there.
Well, kde-redhat probably wants to remain a standalone repository, which doesn't depend on anything else than Fedora Core. It could depend on Fedora Extras, of course.
Hi
The kde-redhat project doesn't fit into the Fedora Extras definition, because it replaces packages in Fedora Core. That makes it either a Fedora Alternatives style repository or a 3rd party repository with even more freedom.
I believe that having the guys from kde-redhat package the kde parts of fedora itself would be a good deal. redhat can focus on gnome integration. this would make sure everyone gets a better deal and share work as suitable. this is also likely to align better with fedora's stated goal of working towards being closer to upstream.
regards Rahul Sundaram
Fredag 05 november 2004 11:49 skrev Michael Schwendt:
The kde-redhat project doesn't fit into the Fedora Extras definition, because it replaces packages in Fedora Core. That makes it either a Fedora Alternatives style repository or a 3rd party repository with even more freedom.
True, but kde-redhat produces a much nicer version of kde than the fedora project. I use both versions every day.
Erik
On Fri, 5 Nov 2004, Michael Schwendt wrote:
On Fri, 5 Nov 2004 16:05:00 +0100 (CET), Dag Wieers wrote:
That page also explains why fedora.us cannot guarantee compatibility with other repositories, quoted below for completeness and as food for discussion. The paragraph is unchanged since April 25th, 2003.
Since fedora.us started without any packages and there were already a number of existing repositories with a good amount of packages. The fedora.us policy could have been to work together with existing repositories and implement something that could have worked.
Sorry that I won't participate in going back to very old threads from fedora-devel@fedora.us list, which were not fruitful. It's beyond my time. The list archives are still open. Everybody is free to skim over the several hundred relevant messages and look at the problem. Okay, I added my comments in this thread, but that's just because I'm subscribed to this list.
Fair enough.
There are a very few people (or maybe it's just one) who don't realize that I'm just a contributor. I'm not in charge of the policies and objectives. I'm not a fedora.us spokesman either. Gah! It's insane to think that, when I never ever claimed to be a spokesman. Fedora.us provides a system which allows community commitment, where I, as a member of the community, can contribute. Other contributors have noticed the possibility, too. On the contrary, when fedora.us was started, and even many months later, no other packaging project was ready to accept community commitment beyond private mails or mailing-lists.
That's not really correct, Michael. It may be your believe, but the fact that at the start most of the 3rd party packagers were involved in fedora.us is a clear indication that we believed in a single merged repository in the long run.
Most existing packagers finally did not believe in the direction fedora.us was going and the way it mandated exactly how it was proceeding without real input from others outside that inner circle. My experience is that that (and of course that RepositoryMixing document) are the real reasons why most of us were put off.
Read that document, go back to the situation 2 years ago and ask yourself why one of us would be interested to join. Ask yourself why one of us would join today ? I think you find more questions than answers. At least if you have listened to our concerns then and now.
An environment, where competition between repositories dominates and crushes any attempts at working towards a higher common goal, is hostile instead of beneficial. Do we all have the same goal with extra packages? No, we don't. Not even with common libraries, I've been told. I understand that e.g. Matthias Saou didn't want to "give up" freshrpms.net in favour of maintaining his packages as part of a project that started as "Fedora Linux". But as could be read on the old fedora-devel list, the other contributors did not see a way to base their project on packages from an external repository, packages which are out of their control.
That's not true. But tell me why we would leave our working environment behind for something that had not proven to work (better!) or did not even listened to our concerns ? Based on that I can only conclude that it was never fedora.us intention to work together.
But that's not really important. The real question is, is there an intention now to find some common ground and loose some of the duplication efforts or not.
You have to know that of course Fedora is a too limited view (I've repeated that before on the fedora.us mailinglists too). Our packages work for much more than just Fedora and our userbase is therefor much wider than only Fedora and only i386.
This should also be appealing to Red Hat, since having a wide set of extra tools and packages that also work for RHEL will only help in selling Red Hat in a lot of environments.
* Users may also have any arbitrary mix of repositories, creating an unsupportable testing nightmare.Which is only true if you have 5 SPEC files resulting in 5 packages, as I said there are other ways to reach the same goal and we've opted to have a single SPEC file resulting (if necessary) into 5 packages. The next step obviously is to look at why we still need 5 packages and how to merge the lot.
Why not take the route of Fedora Extras and extend Fedora Core with add-on packages, which to use as foundation for even more packages? A single easy-to-find place where to get extra packages instead of a multitude of repositories around the world. A single repository which CD manufacturers can mirror and burn onto CD/DVD. A single repository which to include and support directly from within Fedora Core. Why have many 3rd party repositories, which first extend Fedora Core and then extend eachother? Why not create Fedora Extras and then add complementry, special purpose 3rd party repositories, which depend on it?
Ah, I think I just answered these questions. Fedora is only a small subset of what we offer and what we hope to offer. We work not only with the Fedora community, but with lots of other communities too, this helps in getting more feedback and more users that can give good feedback.
I'm sure fedora.us, now that it has packages and is maturing, is working at a slower pace than at the beginning. You can't just change direction anymore if you have a large userbase.
IMHO, the situation hasn't changed at all. The total number of package developers has increased. There are still new submissions added to the package requests queue. But the general willingness to adhere to the policies/guidelines and make _utilisable contributions_ (reviews, approvals, packages which don't fail to build) is still missing. The interest in getting packages accepted and included is there. But the willingness to team up with other developers is missing.
Ok, I thought it was a compliment if I said fedora.us is maturing, but if you say it isn't, I'm not going to argue with you. :)
Let me say that the key to fix what you've just summed up is to have a subversion/CVS in place and make the commits public (or at least public to the packagers). Transparancy is a good way to coherency and to spur discussion to things that really matter. An advice from a fellow packager.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On Fri, 5 Nov 2004 18:46:19 +0100 (CET), Dag Wieers wrote:
There are a very few people (or maybe it's just one) who don't realize that I'm just a contributor. I'm not in charge of the policies and objectives. I'm not a fedora.us spokesman either. Gah! It's insane to think that, when I never ever claimed to be a spokesman. Fedora.us provides a system which allows community commitment, where I, as a member of the community, can contribute. Other contributors have noticed the possibility, too. On the contrary, when fedora.us was started, and even many months later, no other packaging project was ready to accept community commitment beyond private mails or mailing-lists.
That's not really correct, Michael. It may be your believe, but the fact that at the start most of the 3rd party packagers were involved in fedora.us is a clear indication that we believed in a single merged repository in the long run.
Some random excerpts and quotes from the old list, roughly in chronological order:
Nov 2002 : Axel Thimm wants packages to be vendor independent, while Panu Matilainen says that would be beyond his time to test on any other distribution than RH
Nov 20 2002 (Axel Thimm) : Of course only if Matthias is willing to expand his one-man-efford to allow inclusion of trusted third party effords, but this is how he described rpmforge.net. The next step is to have some mechanism for those built packages to enter freshrpms.net.
Feb 5 2003 : Axel Thimm (AT) suggests Epoch bumps for alpha|beta|rc in %version
Mar 1 2003 : controversies about package naming guidelines
AT : That is why one needs to solve the coordination problem of multiple repositories before merging them.
Warren Togami (WT) : The only long term maintainable solution for Fedora is to simply have MORE packages than all other repositories. It was the intent of this project to hopefully unify the various independent packagers and forever put an end to incompatibility.
AT : The second step is to build upon the established situation. freshrpms.net is the standard repository (besides Red Hat), and that is a fact. Anything else that going in harmony with freshrpms is bad. If there are reasons to dislike some of Matthias practices, one should invest time in arguing and coming to an agreement, and not in a takeover. Matthias and Red Hat _are_ the vendors ... ;)
Mar 6 2003 : Warren Togami wants Matthias Saou as release manager Matthias Saou says he doesn't know whether he's suited for that or not. He may be too picky.
March 2003 : Seemingly endless controversies about package versioning and explicit Epochs, package signing,
Mar 7 2003 : Axel Thimm sums up his goals and forsees flames. Message-ID: 20030307101746.GC5882@puariko.nirvana
c) Coming to agreements about general repository guidelines (cerating specifications etc).
d) Consolidating the repositories into one (involving creating the neccessary infratstructure).
that is also the coarse view on milestones, I would set. I know that people want to start at d) and want to get the project rolling at full speed, I'd also like to see the perfect specifications and systems. But the recent discussions about versioning, security infrastructures etc. show that the project should invest more in its planning phase, before getting in the executive one.
IMHO d) depends on Matthias willing to bring his rpms over (better said willing to host the rest of ours - would even solve the name and domain problem ;). I don't forsee that he will do currently something like that, but I never give up hope! ;)
Anyway copying freshrpms.net has already been stated as a bad idea, therefore at least there an interrepository arrangement has to be made. Other smaller repositories (O.K., so I am also thinking about mine ;) would also like to be considered.
Therefore I suggest to have a stronger focus on specifications about inter-repository coordination. Let us coordinate the repositories to such an extend, that one could indeed copy them all together into one.
That would involve a common agreement on versioning and overlapping rpms. I hope that this way more repository owners will be willing contribute, as it merely includes a common sense ;). Having the project rolling in this mode for some time will enable the packagers to establish and learn methods for common "rpm fighting", and give a good taste on fedora. Finally the common repository will be only a matter of infrastructure. :=)
I know I will be flamed, try to be gentle on me. ;)
Mar 11 2003 : Axel and Warren clash, Warren sees large delays in the specification process.
Mar 21 2003 : Dag Wieers joins, active in kernel module packages discussions
Apr 5 2003 : Epoch controversy continued... (Matthias Saou)
"Oh well, seems like I'm the ony one arguing _against_ introducing mandatory epoch fields in all packages... :-("
Apr 19 2003 : AT
Currently fedora is creating the nightmare you mention. People _expect_ different repositories to be mixable, apt and yum provide ways to have different sources, and then you create something incompatible to any other repository out there?
If freshrpms.net is your 'source of inspiration' why do you stab at it (and all the other repositories)? Instead of putting so much energy in replacing or swallowing freshrpms, you could try to extend it. Matthias has signaled to accept patches, if his builds can be improved, and he seems to do so. What was so wrong with freshrpms?
[...]
When I joined fedora I was excited about having a project to create inter-repository coordination and compatibilty rules.
Apr 19 2003 : Dag explains why he replaces packages in freshrpms
Well, I decided to 'replace' some of freshrpms packages because I didn't have control over the dependencies. (Especially for the audio/video packages, this was sometimes a pain) and I couldn't build packages against freshrpms when freshrpms wasn't building against mine ;))
Summary: my repository is self-contained but still compatible with freshrpms.
Apr 19 2003 : Dag continues with inter-repository library standard proposals
May 2003 : Matthias Saou comments on normal discussion, QA work as fedora.us starts, more and more packages appear
July 2003 : Matthias tries to defend his "single person entity"
Nov 8 2003 : Hostile words from Axel Thimm. Panu Matilainen points out that Axel misunderstood the goals of fedora.us
Dag Wieers: [...] most 3rd party packagers already had more packages then Fedora currently.
Whoever may be in search of my first comment on the result of many months worth of discussion, enter the archives around Nov 2003. Older messages from me are unrelated.
The real question is, is there an intention now to find some common ground and loose some of the duplication efforts or not.
Well, let's hope so. Fedora Extras will give the opportunity to extend the package set and also base 3rd party repositories upon it. Then those 3rd party repos no longer need to provide the same libfoo-1.0 that is in Fedora Extras already. Repositories which find Fedora Core not bleeding enough and thus upgrade Fedora Core, will remain a different side of the story.
You have to know that of course Fedora is a too limited view (I've repeated that before on the fedora.us mailinglists too). Our packages work for much more than just Fedora and our userbase is therefor much wider than only Fedora and only i386.
I don't mind distribution-independent packages if I don't need to QA or support them. And if the distribution independence doesn't result in bloated spec files and/or patches, which are more difficult to proof-read. I hope that using a source code management system for packages will avoid that, since it allows forking package development for different distributions. I would not like to spend any time on testing something for rh80, a distribution which is not even supported by Fedora Legacy anymore.
This should also be appealing to Red Hat, since having a wide set of extra tools and packages that also work for RHEL will only help in selling Red Hat in a lot of environments.
I doubt that extra packages alone increase Red Hat's sales. True, there are some customers, who appreciate some prebuilt extra packages (I've seen the messages on taroon-list, too). But increased customer demand would cause Red Hat to become active and support extra software themselves, e.g. anti-virus solutions.
Ok, I thought it was a compliment if I said fedora.us is maturing, but if you say it isn't, I'm not going to argue with you. :)
If you did, I would scratch my head and then shake it in disbelief. ;)
On Fri, 5 Nov 2004, Michael Schwendt wrote:
On Fri, 5 Nov 2004 18:46:19 +0100 (CET), Dag Wieers wrote:
This should also be appealing to Red Hat, since having a wide set of extra tools and packages that also work for RHEL will only help in selling Red Hat in a lot of environments.
I doubt that extra packages alone increase Red Hat's sales. True, there are some customers, who appreciate some prebuilt extra packages (I've seen the messages on taroon-list, too). But increased customer demand would cause Red Hat to become active and support extra software themselves, e.g. anti-virus solutions.
There's a difference between 100 companies wanting the same thing, and 100 companies each wanting a different thing. The second group is as important for sales as the first group. Whether you include it in your distro or not, having a set of 1500 extra packages extending the distro of your choice and having a community around a distro are important factors if you take a long-term decision.
Whether they are prebuilt are not is not really important. The fact that they have been tested and improved by others, is what is of most value.
This is something unique to RHEL and I'm convinced it is a selling point for companies making a decision. Actually I know it is an important factor as I'm using the same argument for advicing RHEL on a daily basis.
There are not many differentiators: bugzilla, Open Source commitment, RHEL community and extra packages are my biggest motivators in favor of Red Hat. Each of these I can back up with examples and anecdotes.
Ok, I thought it was a compliment if I said fedora.us is maturing, but if you say it isn't, I'm not going to argue with you. :)
If you did, I would scratch my head and then shake it in disbelief. ;)
Hehe :)
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On Thu, 2004-11-04 at 17:48, Colin Charles wrote:
On Fri, 2004-11-05 at 01:40 +0100, Dag Wieers wrote:
On Thu, 4 Nov 2004, Colin Charles wrote:
On Wed, 2004-11-03 at 10:46 +0000, Elvis wrote:
Hello everyone Does anyone know of a definitive compatibility list for yum? There are more and more different repos all over the place, some warning not to mix with repo xyz - this can get confusing and trying to keep a stable, up to date box! Could someone point me to a list? or if there are a lot of replies to this, I could make one.
No list, but this is definitely a FAQ
Compatible (definitely, w/assurance):
Fedora.us Livna Jpackage Macromedia Flash (possibly, a little unsure here) Freshrpms
Not-compatible with the above (but maybe with each other): Dag apt.sw.be atrpms (if above fails :P) Freshrpms Nyquist
<insert joe random repo>
Let me add to this that the incompatability of the 3rd party repositories has nothing to do with the inability or unwillingness of the 3rd party packagers (to the contrary). But the unwillingness (and policy) of fedora.us to not allow for compatibility. Apparently it is too hard to work with the community.
And if this is making the FAQ, it should be made clear that:
Dag, newrpms, atrpms, freshrpms are fully compatible with each other (info from http://freshrpms.net/links)
Fedora.us, livna, jpackage, flash is yet another compatible lot
Don't forget to add a link to http://www.fedora.us/wiki/RepositoryMixingProblems
And alas, Dag, and the rest of the repos, I'm sure there's light at the end of the tunnel and if we all forget our differences just for a bit, the Extras thing will be a bigger, greater, reality (no point inter-repo-"fighting", when our goal is to have a great number of packages, when we can truly say, "we package the universe")
Warmest regards
Colin Charles, byte@aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi
We should give Red Hat credit for not "ordering" independent people what to do. If you look at Apple and Microsoft you must do it one way or not at all. Linux is a big sea and Red Hat is only one spot, and they don't try to control the industry.
Someday soon wine or maybe Intel will make it so we can just click on a program and it will run regardless of the OS it's from. And it will be a programmer somewhere in the USA, India, or China that says "I've got it!" Then we'll all be free to pick the programs we like off the shelf or download, pop them in and go.
Tim...
And I think Gandhi would have liked to see every one work together :-)
Tim...
On Fri, 05 Nov 2004 20:57:18 -0800, Timothy Payne wrote:
And I think Gandhi would have liked to see every one work together :-)
But they do want to work together in order to reduce duplication of efforts. The difficult question is: how to achieve that? Difficult because current extra package development is not just redundant and distributed, it's also conflictive. One solution has been discussed before, but to no avail.
On Fri, 5 Nov 2004 01:40:06 +0100 (CET), Dag Wieers wrote:
Let me add to this that the incompatability of the 3rd party repositories has nothing to do with the inability or unwillingness of the 3rd party packagers (to the contrary). But the unwillingness (and policy) of fedora.us to not allow for compatibility. Apparently it is too hard to work with the community.
"If it's not in bugzilla, it's not a bug."
For instance, in bugzilla.fedora.us I've yet to see bug reports from package developers about repository conflicts which are deemed solvable.
And let me add to this discussion, that 3rd party repositories which upgrade Fedora Core, are an unsolvable source of repository conflicts. Not RPM-style file conflicts, but dependency conflicts. If they split their packages into Extras and Alternatives, that would be a first step in the right direction.
Btw, fedora.us is the only repository which has package naming guidelines and other policies published.
On Fri, Nov 05, 2004 at 11:46:57AM +0100, Michael Schwendt wrote:
On Fri, 5 Nov 2004 01:40:06 +0100 (CET), Dag Wieers wrote:
Let me add to this that the incompatability of the 3rd party repositories has nothing to do with the inability or unwillingness of the 3rd party packagers (to the contrary). But the unwillingness (and policy) of fedora.us to not allow for compatibility. Apparently it is too hard to work with the community.
"If it's not in bugzilla, it's not a bug."
It is not a bug, it is a feature of fedora.us:
"The Fedora Linux project has made a decision that we will NOT cooperate with other repositories due to maintain cross-repository compatibilty because it is unmaintainable for several reasons:"
(originally quoted from the wiki, it was deleted from the wiki database the last time I quoted it ...)
For instance, in bugzilla.fedora.us I've yet to see bug reports from package developers about repository conflicts which are deemed solvable.
So why file a bug against a charter? It's like filing a bug against lkml for not running on Windows ...
And let me add to this discussion, that 3rd party repositories which upgrade Fedora Core, are an unsolvable source of repository conflicts.
You always manage to forget the fedora.us patches, and I had to remind you on fedora-de only a couple of months ago (together with the wiki editing/censoring it makes a very funny picture of history revisionism ...)
fedora.us does replace packages on RH8.0-FC1 including critical ones like libsafe or shadow-utils (or also rpm, gftp, gpg & friends). Don't be selective in your memory and arguments, please.
(and before anyone misinterpretes this: these replacements may be for the best of the end-users, just like other third party repos do)
Not RPM-style file conflicts, but dependency conflicts. If they split their packages into Extras and Alternatives, that would be a first step in the right direction.
Btw, fedora.us is the only repository which has package naming guidelines and other policies published.
You mean the guidelines that were crafted together with the other repos and which the other repos abandoned when simple fixes had to be made to make it multi-repo compatible (the same fixes missing today for fedora.us <-> livna compatibility, e.g. livna always wins?)
Please, Michael, there are only very few hard core "there can only be fedora.us" people left, since history has tought otherwise (the ever greatest compatibility issue was fedora.us' _untested_ epoch-0 slamming, not any inter-repo incompatibility).
You always manage to stir up the wall between fedora.us and the rest of the world again. Why? You (inadvertently, of course ...) create an impression of a fedora.us spokesman and people reading your posts think that all of the fedora.us developers have the same Highlander attitude like you do. Step back for a while and watch the others do some _constructive_ integration, will you?
(oh, I forgot, last time I uncovered some wrong statements/lies from you, you placed me in your killfile [1], so I don't really expect and answer ...)
And to whoever from fedora.us is really interested in extending the package universe, please consider ignoring Michael's attitude and try to cooperate with the other repos. This failed in the final composition of fedora.us last year, but hopefully the current set of fedora.us members is more open now (They certainly are, whether the weight is enough for a change of charter is unkown).
Well, in case this is a vote, I place my vote for fedora.us dropping the non-mixing policy. This implies a change of naming guidelines.
[1] http://www.redhat.com/archives/fedora-de-list/2004-May/msg00106.html
Torsdag 04 november 2004 19:40 skrev Dag Wieers:
Let me add to this that the incompatability of the 3rd party repositories has nothing to do with the inability or unwillingness of the 3rd party packagers (to the contrary). But the unwillingness (and policy) of fedora.us to not allow for compatibility. Apparently it is too hard to work with the community.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
I put your repository back into the sources but get this error message. What does that mean?
The following packages will be upgraded lftp wget The following packages have been kept back libpostproc mplayer 2 upgraded, 0 newly installed, 0 removed and 2 not upgraded. Need to get 1111kB of archives. After unpacking 35.5kB disk space will be freed. Do you want to continue? [Y/n] Y Err http://apt.sw.be fedora/2/en/i386/dag lftp 3.0.11-1.1.fc2.dag 404 Not Found [IP: 193.1.219.82 80] Get:1 http://ayo.freshrpms.net fedora/linux/2/i386/updates wget 1.9.1-16.fc2 [452kB] Fetched 452kB in 2s (215kB/s) Failed to fetch http://apt.sw.be/fedora/2/en/i386/RPMS.dag/lftp-3.0.11-1.1.fc2.dag.i386.rpm 404 Not Found [IP: 193.1.219.82 80] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
On Fri, 5 Nov 2004, Erik Kjær Pedersen wrote:
Torsdag 04 november 2004 19:40 skrev Dag Wieers:
Let me add to this that the incompatability of the 3rd party repositories has nothing to do with the inability or unwillingness of the 3rd party packagers (to the contrary). But the unwillingness (and policy) of fedora.us to not allow for compatibility. Apparently it is too hard to work with the community.
I put your repository back into the sources but get this error message. What does that mean?
That you have had bad luck with the mirror and if you tried some time later it would have been corrected by itself. Sadly I don't have much control over the mirror.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
-
Axel Thimm -
Colin Charles -
Craig White -
Dag Wieers -
Elvis -
Erik Kjær Pedersen -
Michael Schwendt -
Rahul Sundaram -
Tim