OK, someone pointed this out to me:
http://www.fedora.us/wiki/RepositoryMixingProblems
Join us or we'll start reproducing your software in your place anyways. Does this not scream arrogance, bureacracy, and monopoly to anybody else? Does this not seem very Microsoft-ish? Can you actually expect to have a single community to maintain every single piece of free software for Fedora Core (talk about a super bloat to the Fedora Project)? Doesn't this seem to go against some of the good things about free software? It seems that a set of extra libraries and applications that aren't "Core" but are still fundamental or very widely used should be the focus of Fedora Extras. Basically, take some software that is very redundantly distributed by other repositories to reduce overlap and increase compatibility, and not try to take over every package that every other repository makes.
Discuss...
William
On Sun, Nov 28, 2004 at 04:11:25PM -0500, William M. Quarles wrote:
Join us or we'll start reproducing your software in your place anyways. Does this not scream arrogance, bureacracy, and monopoly to anybody else? Does this not seem very Microsoft-ish? Can you actually expect
There's been a lot of discussion about this. The points the page makes are real, and declaring their answer "Microsoft-ish" isn't constructive. Do you have an alternate *solution*?
Matthew Miller wrote:
On Sun, Nov 28, 2004 at 04:11:25PM -0500, William M. Quarles wrote:
Join us or we'll start reproducing your software in your place anyways. Does this not scream arrogance, bureacracy, and monopoly to anybody else? Does this not seem very Microsoft-ish? Can you actually expect
There's been a lot of discussion about this. The points the page makes are real, and declaring their answer "Microsoft-ish" isn't constructive. Do you have an alternate *solution*?
I think I have to agree with Mr. Quarles on this one. I don't like the tone of their page. If Fedora Core is supposed to be a community project, there should not be a centralized QA process for "acceptible" packages. The community will decide what works by process of natural selection.
No, they shouldn't be responsible for system stability if a 3rd party package breaks the system. Disclaiming responsibility is fine (and probably the appropraite thing to do). But undermining other repos by using conflicting naming systems IS "Microsoft-ish" (and thus utterly reprehensible) and they should be ashamed of themselves.
If fedora.us wants to start including packages that are already available from FreshRPMs, Dag, etc., they should work with these other repositories' maintainers and contributors. Linux is about collaboration. By trying to assert dominance and control over the community development process, they're only going to alienate users and developers.
I've removed them from my repo list just out of principle.
On Sun, Nov 28, 2004 at 11:44:26AM -1000, Chris Stark wrote:
I think I have to agree with Mr. Quarles on this one. I don't like the tone of their page. If Fedora Core is supposed to be a community project, there should not be a centralized QA process for "acceptible" packages. The community will decide what works by process of natural selection.
Natural selection doesn't work that way. I'll go for a more, um, punctuated equilibrium approach. Throwing all the repositories together into chaos and hoping it all works just isn't going to be any good.
probably the appropraite thing to do). But undermining other repos by using conflicting naming systems IS "Microsoft-ish" (and thus utterly reprehensible) and they should be ashamed of themselves.
Where does it say that FE is planning on using a "conflicting naming system"? (Not on the linked-to fedora.us page....)
If fedora.us wants to start including packages that are already available from FreshRPMs, Dag, etc., they should work with these other repositories' maintainers and contributors. Linux is about collaboration. By trying to assert dominance and control over the community development process, they're only going to alienate users and developers.
There *isn't* a community development process yet. But it's still promised as "really just around the corner real soon now", and I'm willing to wait a little bit longer. There _has_ to be some centralized quality control, just to make sure everything can coexist properly. Mini-repositories operating in a vacuum are, as the page says, inevitably going to have clashes.
(This is why DAG, FreshRPMS, et al. are also working on coordinating more closely, which is _also_ a very good thing.)
I've removed them from my repo list just out of principle.
Heh. Have fun with that.
Matthew Miller wrote:
On Sun, Nov 28, 2004 at 11:44:26AM -1000, Chris Stark wrote:
I think I have to agree with Mr. Quarles on this one. I don't like the tone of their page. If Fedora Core is supposed to be a community project, there should not be a centralized QA process for "acceptible" packages. The community will decide what works by process of natural selection.
Natural selection doesn't work that way. I'll go for a more, um, punctuated equilibrium approach. Throwing all the repositories together into chaos and hoping it all works just isn't going to be any good.
Matthe hat's not we are suggesting. You are replying to our statements out of context. Later on in Chris' same message he does suggest a more mature approach, as did I. You jumped on me for "not having any suggestions" when I clearly had made suggestions. Calm down the impulsivity and have a more open mind, please.
probably the appropraite thing to do). But undermining other repos by using conflicting naming systems IS "Microsoft-ish" (and thus utterly reprehensible) and they should be ashamed of themselves.
Where does it say that FE is planning on using a "conflicting naming system"? (Not on the linked-to fedora.us page....)
I know nothing about that.
If fedora.us wants to start including packages that are already available from FreshRPMs, Dag, etc., they should work with these other repositories' maintainers and contributors. Linux is about collaboration. By trying to assert dominance and control over the community development process, they're only going to alienate users and developers.
There *isn't* a community development process yet. But it's still promised as "really just around the corner real soon now", and I'm willing to wait a little bit longer. There _has_ to be some centralized quality control, just to make sure everything can coexist properly. Mini-repositories operating in a vacuum are, as the page says, inevitably going to have clashes.
Fedora Extras was supposed to be a community project from the beginning. It did not come from Red Hat like Fedora Core did. There should be a community on Fedora Extras now. And if this is a respected part of the Fedora Project, I am sure having a hard time finding the link from fedora.redhat.com to fedora.us. The only way that I ever found out about Fedora Extras was through this mailing list.
Several of the other repositories of which we speak are far from "mini." They have been around longer and are still more popular than Fedora Extras. Some have more packages. Most have much better designed and more sophisticated websites.
Also, some include packages (like the ever-popular Xine) that were once part of Red Hat Linux but were dropped in the transition to Fedora Core. For some reason those packages never made it into Fedora Extras. As an aside, why are we still avoiding MPEG technologies in The Fedora Project, especially when it is not a product that is bought and sold? The courts already upheld the right of open source development and distribution of independently developed MPEG software.
(This is why DAG, FreshRPMS, et al. are also working on coordinating more closely, which is _also_ a very good thing.)
And why can't Fedora Extras participate in that same process like we were suggesting? Oh, I forgot, they're still trying to act like Microsoft.
I've removed them from my repo list just out of principle.
Heh. Have fun with that.
He's got plenty of worthwhile options to choose from.
---- Peace, William
William M. Quarles wrote:
Fedora Extras was supposed to be a community project from the beginning. It did not come from Red Hat like Fedora Core did. There should be a community on Fedora Extras now. And if this is a respected part of the Fedora Project, I am sure having a hard time finding the link from fedora.redhat.com to fedora.us.
Bravo!
The only way that I ever found out about Fedora Extras was through this mailing list.
I actually found out about it from one of the books I'd read on Fedora. On a related note, most books I've read on Fedora point you to places like freshrpms. No mention of "fedora.us" at all..
Several of the other repositories of which we speak are far from "mini." They have been around longer and are still more popular than Fedora Extras. Some have more packages. Most have much better designed and more sophisticated websites.
Indeed. From DAG's site: "I currently have *24141* packages available for different Red Hat flavors. (6.2, 7.3, 8.0, 9, EL2.1, EL3, FC1, FC2 and FC3). They comprise *1344* different projects."
Also, some include packages (like the ever-popular Xine) that were once part of Red Hat Linux but were dropped in the transition to Fedora Core. For some reason those packages never made it into Fedora Extras. As an aside, why are we still avoiding MPEG technologies in The Fedora Project, especially when it is not a product that is bought and sold? The courts already upheld the right of open source development and distribution of independently developed MPEG software.
(This is why DAG, FreshRPMS, et al. are also working on coordinating more closely, which is _also_ a very good thing.)
And why can't Fedora Extras participate in that same process like we were suggesting? Oh, I forgot, they're still trying to act like Microsoft.
I've removed them from my repo list just out of principle.
Heh. Have fun with that.
He's got plenty of worthwhile options to choose from.
Indeed. I nixed fedora.us as soon as I learned they don't play nice and I've done quite fine without them.......
Scott
On Mon, Nov 29, 2004 at 01:42:45PM -0500, William M. Quarles wrote:
Matthe hat's not we are suggesting. You are replying to our statements out of context. Later on in Chris' same message he does suggest a more mature approach, as did I. You jumped on me for "not having any suggestions" when I clearly had made suggestions. Calm down the impulsivity and have a more open mind, please.
Sorry; I mean to be harsh. However, the original post had quite an inflamatory tone.
Fedora Extras was supposed to be a community project from the beginning. It did not come from Red Hat like Fedora Core did. There should be a community on Fedora Extras now. And if this is a respected part of the Fedora Project, I am sure having a hard time finding the link from fedora.redhat.com to fedora.us. The only way that I ever found out about Fedora Extras was through this mailing list.
Check this out, from the devel list:
http://www.redhat.com/archives/fedora-devel-list/2004-November/msg01170.html
Several of the other repositories of which we speak are far from "mini." They have been around longer and are still more popular than Fedora Extras. Some have more packages. Most have much better designed and more sophisticated websites.
This is definitely true. Others aren't and don't, though -- but some still have very good packages. There needs to be coordination.
Also, some include packages (like the ever-popular Xine) that were once part of Red Hat Linux but were dropped in the transition to Fedora Core.
This is an excellent example of one of the problems. One of Xine's main features is playing DVDs, which is (sadly) on very thin legal ice in the US. Fedora Extras as a US-based project would have to include a stripped-down version -- and that doesn't seem very useful.
For some reason those packages never made it into Fedora Extras. As an aside, why are we still avoiding MPEG technologies in The Fedora Project, especially when it is not a product that is bought and sold? The courts already upheld the right of open source development and distribution of independently developed MPEG software.
Because Fedora _can_ be bought and sold, even if Red Hat isn't doing it. That's supposed to be one of the key features of open source.
(This is why DAG, FreshRPMS, et al. are also working on coordinating more closely, which is _also_ a very good thing.)
And why can't Fedora Extras participate in that same process like we were suggesting? Oh, I forgot, they're still trying to act like Microsoft.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Oh come on. What happened to the "more mature approach"?
Heh. Have fun with that.
He's got plenty of worthwhile options to choose from.
It seems a funny thing to make a stand on, is all. Probably should stop using the Fedora Core base too.
On Mon, 29 Nov 2004 13:42:45 -0500, William M. Quarles quarlewm@jmu.edu wrote:
Several of the other repositories of which we speak are far from "mini." They have been around longer and are still more popular than Fedora Extras. Some have more packages. Most have much better designed and more sophisticated websites.
There main issues... once you let yourself get beyond the heated bloodlust between certain members in the discussion.... is the issue of which world view you think is best long term. And please, you have to take some of the more aggressive statements on both sides in context. The discussion about this has gone on for years now... well before Red Hat decided to name their project "Fedora." The main parties in the debate reached a standoff several eons ago, some of them just haven't realized there comes a point when you have to stop and just agree to disagree, because sometimes perfectly rational people will disagree for perfectly rationale reason. Though I will say, I think too many people are behaving irrationally at this point for continued discussion to be worthwhile. And to dwell on "propaganda"... especially wiki comments that were reworded in an effort to be more considerate..seems a delibrate ploy to keep the issues heated well past the point where its constructive to do so. People make mistakes, people get upset and mispeak, to dwell on this does not move things forward.
I personally think it comes down to how you prioritize certain aspects of the issue at hand relative to each other. In essense there are two long term competing world views. Not 3 months from now... not 6 months from now... think fc6 time schedule. Do you want to see as much centralized system into one (or two) repository as possible. Or do you want to see a several competing repositories each with overlap sets of packages as the long term solution? Each has its strengths and weaknesses depending on what solution you are trying to solve.
I personally think moving to as much centralization provides a more interesting Fedora Project. I like the idea Micheal Tiemann of Red Hat has express about "Fedora Collections" where in the future once Core and Extras exist in the same build environment you think about opening up the space and having targetted media sets besides just Core, put together from core and extras. I'm also concerned about relying on system made of nearly individual packagers maintaining their own individual repositories and build systems. I'm concerned about what happens if one those individuals can no longer provide packages any longer. Since there is no integrated build system between individual repositories, it might be a significant amount of time for a volunteer to duplicate the build system that repository was using if it goes dark due to an individual maintainers. If an individual maintainer can no longer package in a centralized build system... a volunteer does not need to try to duplicate any of the build infrastructure to come forward and maintain the packages that were orphaned.
I have several other reasons why I personally prefer a long term centralized solution, but i would have to say those are my two primary reasons. And i think its important that we all take a moment and think about long term priorities and constraints, instead of getting caught up in the day to day, back and forth debate. Without taking anything away from those people who volunteered their efforts to create large repositories of packages for the general public to use, in the guideline vacuum Red Hat created for add-on packages through the entire RHL period.. i think the long term health of Fedora is best served with as much centralization of package build process as possible moving forward.
-jef
Jeff Spaleta wrote:
<snip>
I personally think it comes down to how you prioritize certain aspects of the issue at hand relative to each other. In essense there are two long term competing world views. Not 3 months from now... not 6 months from now... think fc6 time schedule. Do you want to see as much centralized system into one (or two) repository as possible. Or do you want to see a several competing repositories each with overlap sets of packages as the long term solution? Each has its strengths and weaknesses depending on what solution you are trying to solve.
Fedora Core 6 will only be a year from now, not mush of a stretch from six months. I think that you should keep that in mind as you throw around that number.
And the repositories don't all compete with each other. That's only how Fedora Extras sees it, because THEY are the newcomers trying to compete with all of the other repositories. A lot of the non-Fedora-Extras repositories are interoperable now because the individual maintainers have been working together on that. That has been emphasized several times already on and off of this thread. I think that it was either Axel or Dag that said that the repository world has been broken down now into only two camps, not 4, not 3, only two: Fedora.us, and non-Fedora.us.
I personally think moving to as much centralization provides a more interesting Fedora Project. I like the idea Micheal Tiemann of Red Hat has express about "Fedora Collections" where in the future once Core and Extras exist in the same build environment you think about opening up the space and having targetted media sets besides just Core, put together from core and extras. I'm also concerned about relying on system made of nearly individual packagers maintaining their own individual repositories and build systems. I'm concerned about what happens if one those individuals can no longer provide packages any longer. Since there is no integrated build system between individual repositories, it might be a significant amount of time for a volunteer to duplicate the build system that repository was using if it goes dark due to an individual maintainers.
Probably that repository will merge with another well-established repository, and then that individual will pick up the packaging with their pre-existing build system. I'm not worried about that happening anytime soon with Planet CCRMA, my main repository, because Fernando gets paid by Stanford University to maintain it, and if he leaves they'll probably hire somebody else in his stead.
If an individual maintainer can no longer package in a centralized build system... a volunteer does not need to try to duplicate any of the build infrastructure to come forward and maintain the packages that were orphaned.
A volunteer would still have to come forward to keep maintaining that particular package however. I'm sure that far from all of the packages will be popular to maintain.
I have several other reasons why I personally prefer a long term centralized solution, but i would have to say those are my two primary reasons. And i think its important that we all take a moment and think about long term priorities and constraints, instead of getting caught up in the day to day, back and forth debate. Without taking anything away from those people who volunteered their efforts to create large repositories of packages for the general public to use, in the guideline vacuum Red Hat created for add-on packages through the entire RHL period.. i think the long term health of Fedora is best served with as much centralization of package build process as possible moving forward.
I don't completely disagree with that. I just think that their should be some centralization, mainly libraries, and also programs that are useful mainly because a lot of other programs use them. These would be packages that would not be relevant to Core but would be relevant to programs outside of core. And leave open some "third-party" communication. That will increase interoperability immensely, while still leaving some spice in the world. It will also leave the door open for people who actually want to write software for Fedora Core commercially (especially companies that write software that people want but nobody else wants to program) to interact with the Fedora Extras community, making it even bigger, brighter and more interesting... gosh, imagine that!
---- Peace, William
On Tue, 2004-11-30 at 09:51, William M. Quarles wrote:
And the repositories don't all compete with each other. That's only how Fedora Extras sees it, because THEY are the newcomers trying to compete with all of the other repositories. A lot of the non-Fedora-Extras repositories are interoperable now because the individual maintainers have been working together on that. That has been emphasized several times already on and off of this thread. I think that it was either Axel or Dag that said that the repository world has been broken down now into only two camps, not 4, not 3, only two: Fedora.us, and non-Fedora.us.
To get this right for interoperability with all repos and end this war is for fedora.us to play nice with others? Which as I understand it from reading this thread is being stopped by "(very) few black sheep" (to quote Axel). Now I have to ask, Why can't you? Whats preventing you? It seems that Everyone but you guys can't come to an agreement on the whole process. Explain to us (atleast me) what makes your way better than all the other repos?
Hi
. Explain to us (atleast me) what makes your way
better than all the other repos?
look. the whole discussion has turned non productive. Fedora extras is said to be announced in a short while.. after that has been created there will be a fresh oppurtunity to start from scratch till then please drop this bickering
On Tue, 2004-11-30 at 10:10, Rahul Sundaram wrote:
Hi
. Explain to us (atleast me) what makes your way
better than all the other repos?
look. the whole discussion has turned non productive. Fedora extras is said to be announced in a short while.. after that has been created there will be a fresh oppurtunity to start from scratch till then please drop this bickering
I have heard dags side from dag himself, the technical answer. I haven't heard from fedora.us on why its process is better, I never asked them now I am. I just want to hear it from them. Yeah my words weren't exactly the nicest way to put it. But I still haven't heard from them exactly as to the technical why. They can reply to me off list as to why. All I hear is that fedora.us wants it one way and the rest do it another. And that they reject anyone else. Thats what has come across to me besides a war of words.
-- Regards, Rahul Sundaram
On Tue, 2004-11-30 at 10:20 -0800, Mike Ramirez wrote:
On Tue, 2004-11-30 at 10:10, Rahul Sundaram wrote:
Hi
. Explain to us (atleast me) what makes your way
better than all the other repos?
look. the whole discussion has turned non productive. Fedora extras is said to be announced in a short while.. after that has been created there will be a fresh oppurtunity to start from scratch till then please drop this bickering
I have heard dags side from dag himself, the technical answer.
I haven't heard such thing from Dag. I saw Dag and me talking past each other, and I saw Axel, Michael and Dag agitating.
I haven't heard from fedora.us on why its process is better,
Fedora.US isn't any better or worse than Dag, Axel or Freshrpms.
It is one party amongst them and many others more. It's your choice to use the repository you prefer and feel comfortable with.
Fedora.Extras shall be run by RH and will primarily be derived from packages now being part of Fedora.US and other repositories.
To reiterate http://fedora.redhat.com: -- begin of citation --- The Red Hat Linux Project, as this used to be called, is merging with the Fedora Linux project (http://www.fedora.us). We had so many common goals that to work apart would be a waste of effort. We have months of effort before we can have a unified infrastructure, so we still have two different web sites, two sets of documentation, and so forth, but we will be unifying our work over time. Red Hat would like to thank Fedora Linux project developers for proposing the merger and committing time to making the merger a reality. -- end of citation --
All I hear is that fedora.us wants it one way and the rest do it another. And that they reject anyone else. Thats what has come across to me besides a war of words.
Forget about these discussions and those who prefer to hang on to the past. These discussions are moot. RH and others currently are merging those packages from Fedora.US and from some other sites into what is supposed to become Fedora.Extras.
It's up to the users to decide on using Fedora.Extra or not.
Ralf
On Tue, 2004-11-30 at 14:05, Ralf Corsepius wrote:
On Tue, 2004-11-30 at 10:20 -0800, Mike Ramirez wrote:
On Tue, 2004-11-30 at 10:10, Rahul Sundaram wrote:
Hi
. Explain to us (atleast me) what makes your way
better than all the other repos?
look. the whole discussion has turned non productive. Fedora extras is said to be announced in a short while.. after that has been created there will be a fresh oppurtunity to start from scratch till then please drop this bickering
I have heard dags side from dag himself, the technical answer.
I haven't heard such thing from Dag. I saw Dag and me talking past each other, and I saw Axel, Michael and Dag agitating.
It wasn't on a list but ICQ. I don't think you would see such a thing. If Dag allows I can find the logs.
I haven't heard from fedora.us on why its process is better,
Fedora.US isn't any better or worse than Dag, Axel or Freshrpms.
It is one party amongst them and many others more. It's your choice to use the repository you prefer and feel comfortable with.
Fedora.Extras shall be run by RH and will primarily be derived from packages now being part of Fedora.US and other repositories.
My only goal is to get a solution so everyone involved is happy and know one feels bad or hurt or anything esle. Then we can past this bickering or if not please then drop the bickering from public view it doesn't look good IMO.
On Tue, 30 Nov 2004 15:21:17 -0800, Mike Ramirez mike@thexxxhost.com wrote:
My only goal is to get a solution so everyone involved is happy and know one feels bad or hurt or anything esle.
As soon as preventing hurt feelings becomes the goal for any technical solution... you have allowed emotion to trump technical merit and substantiative progress. The only way to avoid bad feelings is to keep the discussion above personal politics, stay focused on larger goals, and to make sure everyone communicates their priorities up front. New solutions may or may not obsolete previous attempts to solve the problem... and you can't even count on different people to define the problem to be solved similarly. But we must not let the emotional attachment to any specific technical implementation hold us back from choosing the best solution to solve the larger priorities and to make the best use of the resources at hand. It's unfortunate that this issue has become personal to a number of people, but I will not let personal politics hold the progress of the Fedora project hostage. There is a saying about omelets and broken eggs that would seem appropriate.
-jef"my love for omelets is just a convenient covert for my fetish for breaking eggs"spaleta
On Tue, 2004-11-30 at 15:44, Jeff Spaleta wrote:
On Tue, 30 Nov 2004 15:21:17 -0800, Mike Ramirez mike@thexxxhost.com wrote:
My only goal is to get a solution so everyone involved is happy and know one feels bad or hurt or anything esle.
As soon as preventing hurt feelings becomes the goal for any technical solution... you have allowed emotion to trump technical merit and substantiative progress. The only way to avoid bad feelings is to keep the discussion above personal politics, stay focused on larger goals, and to make sure everyone communicates their priorities up front. New solutions may or may not obsolete previous attempts to solve the problem... and you can't even count on different people to define the problem to be solved similarly. But we must not let the emotional attachment to any specific technical implementation hold us back from choosing the best solution to solve the larger priorities and to make the best use of the resources at hand. It's unfortunate that this issue has become personal to a number of people,
Agreed
I also have apologized to Michael in a reply to an email he set me detailing the problems and the situation as I needed to find out but about what I said but in the end it was act of anger at the thread, the problems and the lack of a real solution, that helps everyone and the what seemed to me as a lack of explanation from fedora.us on this stance of its our way or the highway policy. I apologized to him because they were aimed at him as he seemed to be the biggest hindrance to a global solution. If you were offend I apologize. But I also detailed to him my idea of a solution. Which I will put here. Basically turn Fedora Extras into a community project form one repo with multiple repos and maintainers but one set of guidelines decided upon by the community to for them all to follow that define build machines and so on. With some sort of disciplinary action for not following these guidelines. Just compromise on these guidelines will have to be met and enforced. Is it possible in reality IDK. But I think it will bring in the much needed resources for this project. Is it the right answer? IDK again, Thats up to everyone involved if we can leave egos and personal feelings at the door. For some it doesn't seem possible but they will have to learn. If not I don't see a solution that will help us but keep it as it is. Is that what is really needed? IDK either. Its up to you guys who do this full time. In the end I only want whats best to help the fedora project and Linux in whole to move forward. My first post didn't do that I know and apologize for it.
Another old saying no use crying over spilled milk.
On Tue, 2004-11-30 at 15:21 -0800, Mike Ramirez wrote:
On Tue, 2004-11-30 at 14:05, Ralf Corsepius wrote:
On Tue, 2004-11-30 at 10:20 -0800, Mike Ramirez wrote:
On Tue, 2004-11-30 at 10:10, Rahul Sundaram wrote:
Hi
. Explain to us (atleast me) what makes your way
better than all the other repos?
look. the whole discussion has turned non productive. Fedora extras is said to be announced in a short while.. after that has been created there will be a fresh oppurtunity to start from scratch till then please drop this bickering
I have heard dags side from dag himself, the technical answer.
I haven't heard such thing from Dag. I saw Dag and me talking past each other, and I saw Axel, Michael and Dag agitating.
It wasn't on a list but ICQ. I don't think you would see such a thing. If Dag allows I can find the logs.
I haven't heard from fedora.us on why its process is better,
Fedora.US isn't any better or worse than Dag, Axel or Freshrpms.
It is one party amongst them and many others more. It's your choice to use the repository you prefer and feel comfortable with.
Fedora.Extras shall be run by RH and will primarily be derived from packages now being part of Fedora.US and other repositories.
My only goal is to get a solution so everyone involved is happy and know one feels bad or hurt or anything esle. Then we can past this bickering or if not please then drop the bickering from public view it doesn't look good IMO.
Discussion is healthy. Hiding what is discussed from public view will not help in any way.
Who cares about the "doesn't look good" attitude. If I cannot say what I feel in a forum where others can respond then we lose the freedom to have realistic discussions and present our views. If I have to be 'politically correct' and only discuss items and views that look good, then my views are being censored.
Just because you do not agree with me does not mean your view is better, nor that mine is better, They are different and both equally valid.
You are not forced to read this thread, and if you wish can even filter it out, but it is perfectly valid as a discussion topic. It is even exactly "on topic" because it relates to fedora overall.
On Tue, 30 Nov 2004 12:51:08 -0500, William M. Quarles quarlewm@jmu.edu wrote:
And the repositories don't all compete with each other. That's only how Fedora Extras sees it, because THEY are the newcomers trying to compete with all of the other repositories.
I use the term compete.. in a larger sense then you do. I look at any duplication of effort, to package the same packages in different locations as competition for manpower. I believe the entire process is manpower limited, and I believe it is wise to reduce the amount of manpower used on inter-repo regression testing and use it for other things. Disagreements at this level come down to priorities, resource allocation and priorities. While there is always a place for divergence and duplicated effort.. as a generator for innovation and experimentation. I see no reason to spend the man-power to encourage a mainline process that makes duplication of effort as central approach to mainstream package distribution and maintaince.
And please, you need to understand this is no longer a fedora.us against the repository establishment. Red Hat made a decision to merge fedora.us into the larger Fedora project. Red Hat is not a newcomer to the issue of packaging. We must not look at this from a territorial perspective, this is about making policy that best benefits the project long term. What you see as "new comer" symdrome.. i see as growth of a older distribution to encompass a larger mission. Can it be a bad thing that the distributing is growing to encompass more functionality? You can either agree that centralization is a good thing and will use your limited resources and your limited time to move towards that direction. Or you will disagree with centralization and will work against it. I personally choose to work towards centralization, and find the cost of inter-repo regression testing to be a poor use of limited time and limited manpower resources. Everything has an opportunity cost, and I would much rather see Core and Extras developers concetrating there limited time and limited resources on working inside a centralized non-overlapping buildsystem than having to try to keep up with 5 or 10 or 15 variations of conflicting packages from a variety of locations. I don't even expect Core and Extras developers to have to be concerned with Fedora Alternatives when Alternatives walks out of the vapor somewhere down the line.
A lot of the non-Fedora-Extras repositories are interoperable now because the individual maintainers have been working together on that.
And they have their priorities... to them.. doing this makes a lot of sense because of the constraints and priorities from their perspective based on their history. Red Hat on the other hand has a longer history and a different perspective... and have chosen to merge with fedora.us into the larger Fedora project.
That has been emphasized several times already on and off of this thread. I think that it was either Axel or Dag that said that the repository world has been broken down now into only two camps, not 4, not 3, only two: Fedora.us, and non-Fedora.us.
That is their opinion, and i think they are very good at choosing language that makes them out to be the victim in a personal way. I don't think these sorts of comments are constructive and it greatly dimishes the level of discourse. We must move beyond "us versus them" mentalities. I dont think its useful to talk about "repositories" when counting heads in this fashion. I think its useful to talk about the number of human packagers. Again I believe that the process is in general manpower limited. A centralized...common buildsystem model.. scales to many humans much better than the.. small group of humans per repository model. Its a matter of economics of scale. And I also believe that centralization makes it much easier to keep the communication flowing from users..to packagers...to developers. I believe it will be much easier for upstream developers to become more involved with distribution level bugreporting and fixing if there is centralization of packages for the specific distribution.
I also believe that centralized model lowers the bar for all potential packagers who enter the community in all future times. A centralized model, established and makes avaliable a set of common best practise tools and build system to ALL new packagers who enter the system. The centralized model provides inherent mechanism for mentoring. The small group model on the other hand raises the bar for all new packagers who need to not only learn best practises on their own but must build their own build system and distribution infrastructure for their own repository, and then must build their own repository brandname in the community competing for mindshare with established repositories. The issues surrounding brand identification alone probably limit the number of repositories in this model to something like 15 or 20 "popular" locations, before the community is unable to keep up with all of them in a meaningful way.
A volunteer would still have to come forward to keep maintaining that particular package however. I'm sure that far from all of the packages will be popular to maintain.
You skirt my main point.... it its absolutely much easier for a volunteer to come forward.. if there is a pool of packagers who understand the build system being used for the now unmaintained packages. When you have different repositories....you have different build systems. You lower the bar greatly to a new maintainer if the new maintainer is already building packages on the same build system as the unmaintained packages. The more packagers using the same tools.. the more packagers who are qualified to volunteer. The process is manpower limited... creating a system and a process.. that makes it easy for a package to switch ownership to another maintainer fluidly is an important step in making sure manpower is being used effectively. I believe making inter-repository regression testing a priority is a waste of manpower that can be used for other more important things.
I don't completely disagree with that. I just think that their should be some centralization, mainly libraries, and also programs that are useful mainly because a lot of other programs use them. These would be packages that would not be relevant to Core but would be relevant to programs outside of core. And leave open some "third-party" communication.
No one is preventing anyone from doing whatever third-party communication they want to do as individual packagers. But we are talking about specific policy statements... and i see no reason to mandate that all packagers in Core and Extras make the effort to regression test with outside repositories as a matter of policy. In fact, i believe such testing is a waste of limited resources that could be used for other purposes.
-jef
On Tue, 2004-11-30 at 11:10, Jeff Spaleta wrote:
In fact, i believe such testing is a waste of limited resources that could be used for other purposes.
Hi Jeff
I think you answered my why question and can agree with you an almost everything said. This here I think is wrong. This testing is necessary or we will always have this same problem. I think a compromise must be made in this area to have cross compatibility between all repos for a better user experience.
Otherwise it will stay as it is. Is this a good thing? or a bad thing? I think this thread has pointed out that its bad and needs to be fixed. Otherwise people will always have to choose between fedora extras and the rest of the third party repos.
You are right with limited resources but if BOTH sides work TOGETHER to solve this and find a middle ground a positive answer can be found. By rejecting other established repos you cut your resources even more and thats your biggest gripe about not being able to do this testing.
Until something can be done in this area I don't think alot of new users will have a positive experience with Fedora and installing packages not part of the Core distribution. If I'm right will this help or hurt Fedora as a whole?
I have in the past made a decision not to use fedora.us packages and use only certain repos mainly to avoid the compatibility problems. I would rather be able to have a real choice solely on content to use a repo or not. Not because this one works with this one and this one doesn't. New users won't really understand that right away. I know I didn't. What is the answer to this? This is what has been asked before and I'm asking again. How can we get interoperability between ALL repos or is that just impossible now?
This question goes out to all repos not just Fedora Extras but EVERY repo maintainer and packager around the world.
On Tue, 30 Nov 2004 12:00:27 -0800, Mike Ramirez mike@thexxxhost.com wrote:
On Tue, 2004-11-30 at 11:10, Jeff Spaleta wrote:
In fact, i believe such testing is a waste of limited resources that could be used for other purposes.
Hi Jeff
I think you answered my why question and can agree with you an almost everything said. This here I think is wrong. This testing is necessary or we will always have this same problem. I think a compromise must be made in this area to have cross compatibility between all repos for a better user experience.
All repos? ALL REPOS? thats a very very big number. You realize that individual red hat developers have their own repos at people.redhat.com used for a variety of reasons...hell even projects at sf.net have package repositories that some users eat packages from. You must count those micro repos in that ALL REPOS matrix. To test against ALL REPOS its an absurd waste of time.
My answer is to stop using the outside repos for as many packages as possible. "Established" is a misnomer, and suggests the only repositories worth doing regression testing against are a small handful of repos. If the number of overlapping "established" repos grows over time the testing matrix grows exponentially harder to manage... this does not scale. This system either throws up barriers to entry to new packagers with new repositories...or it breaks down continually into smaller groups. 100 repositories will not be able to cross-communicate as affectively as 10. 10 repositories will not be able to cross-communicate as effectively as 5. and so on. What scales... is moving more and more packages into the SAME build system into a non-overlapping tree, and encouraging users to use packages from that build system.
My sincere hope is that this project and this community will move towards a situations where you have 2 centralized build systems. One build system managed by Red Hat and containing everthing Fedora policy can legally distributed. A second non-US build system maintained by community for packages that can not be re-distributed by red hat. In my perfect future, Red Hat will be able to provided a blueprint and tools for the non-US community buildsystem to replicate using community donations for hardware and community volunteers to staff the system with manpower. In my perfect future the non-US buildsystem builds on top of the Red Hat build system but does not overlap. In my perfect future both build systems follow very closely to the current Core development model, where much of the energy is focused on a development "truck" and individual packagers in the system have the freedom to create experiment sidebar repositories non unlike what we see in people.redhat.com today.
Otherwise it will stay as it is. Is this a good thing? or a bad thing? I think this thread has pointed out that its bad and needs to be fixed.
It does need to be fixed... i would fix it by no longer having multiple 3rd party repositories. I would fix it... by establishing a common buildsystem and common distribution tree. If you don't have multiple repositories aimed at general consumption... then you don't have repository conflicts.
asking again. How can we get interoperability between ALL repos or is that just impossible now?
ALL repos... is impossible and will continue to be impossible. There are hundreds of small repositories out there. Do you really think you can get hundreds of individual repositories all working together?
-jef
On Tue, 2004-11-30 at 12:43, Jeff Spaleta wrote:
On Tue, 30 Nov 2004 12:00:27 -0800, Mike Ramirez mike@thexxxhost.com wrote:
On Tue, 2004-11-30 at 11:10, Jeff Spaleta wrote:
In fact, i believe such testing is a waste of limited resources that could be used for other purposes.
Hi Jeff
I think you answered my why question and can agree with you an almost everything said. This here I think is wrong. This testing is necessary or we will always have this same problem. I think a compromise must be made in this area to have cross compatibility between all repos for a better user experience.
All repos? ALL REPOS? thats a very very big number.
I understand that but it brings you the resources you need. You say the resources are limited, you need them from somewhere? All I read was an excuse as not to do it. We don't need excuses anymore but an answer. Is yours the best I don't know. Hopefully with enough replies we will find out.
I might be thought of an idiot for this past post. But the goal is to find the best answer possible. I definitely don't have a full one but an Idea and if you can't do it with your available resources you need them from somewhere, I'm just trying to help you find them with whats available. Egos need to be checked and an answer found IMO. We should be open to all solutions and not think ours is the best. Two build machines for how many thousands of extra packages? Is that really a doable situation? Its Ideal yeah but is more than that? I don't know. The number of packages that would need to be done just doesn't seem like its really possible. I'm just trying to provide a solution that will help everyone. It may not be the right one but hopefully it pushes one that works and satisfies everyone involved.
On Tue, 30 Nov 2004, Jeff Spaleta wrote:
On Tue, 30 Nov 2004 12:51:08 -0500, William M. Quarles quarlewm@jmu.edu wrote:
I look at any duplication of effort, to package the same packages in different locations as competition for manpower. I believe the entire process is manpower limited, and I believe it is wise to reduce the amount of manpower used on inter-repo regression testing and use it for other things.
Why don't you start lowering the manpower by automating stuff and allow people to play along. Even if I would submit _all_ my packages today (which I can't because of policy reasons of fedora.us and because the limited scope of fedora.us) it would not be technical feasible.
The day I do that, the QA queue of fedora.us will be 4x as big as it is now and it will take a long time for these packages to even hit the repository (if ever).
I wouldn't be able to update or add new packages because of the overhead that is demanded of me by the policies and procedures that currently lack any automation or infrastructure.
There is a reason why there still aren't any FC3 packages. I don't want to pressure Red Hat and I think this thread is not worth everyone's time spend. But don't give the impression that I'm not willing to cooperate or that it is possible to add packages today, because it simply is NOT.
First work on the infrastructure before you add voluntary manpower, otherwise you're effectively wasting manpower and potentially ruining a community project. It currently does not scale, tools are missing.
Disagreements at this level come down to priorities, resource allocation and priorities. While there is always a place for divergence and duplicated effort.. as a generator for innovation and experimentation. I see no reason to spend the man-power to encourage a mainline process that makes duplication of effort as central approach to mainstream package distribution and maintaince.
Look, we've effectively zero'd all duplication effort by simplying sharing and merging our SPEC files and SPEC development. 4 repositories now are no longer developing their own stuff. They only build the same stuff because we're still in a transit phase. ZERO duplication in less than a week after Fosdem. No magic powder was necessary.
And having a single subversion makes it very cheap to work towards the same policies regarding SPEC file management, because everyone can *see* what other people are doing, things are discussed openly and coherency is established almost instantly.
So there are other ways to get rid of wasted manpower than aiming for the ideal, utopic goal. You can take a shortcut, but it may take you longer to actually get somewhere.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On Wed, 1 Dec 2004, Dag Wieers wrote:
First work on the infrastructure before you add voluntary manpower, otherwise you're effectively wasting manpower and potentially ruining a community project. It currently does not scale, tools are missing.
Let me also add that the main reason why I'm not involved in fedora.us is because I'm not using the repository because I can not. It had conflicts with my own repository and their policy is not spend time on compatibility.
So they've shut me out. The day that policy is lifted there would be a reason for me to file some bugreports for compatibility reasons, then enable fedora.us and then do bugreports about those packages I use from fedora.us.
I'm not using any, so I can't comment on them. I only know what breaks because of reports and even for that I can't offer any help.
PS I do provide bug reports for Red Hat/Fedora Core packages. PS2 I'm using fedora.us carefully, and try not to mix it with Fedora Extras
Jeff, next time you comment about 3rd part repositories I would like you to read the previous mail and this mail.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On Wed, 1 Dec 2004 01:53:30 +0100 (CET), Dag Wieers dag@wieers.com wrote:
Why don't you start lowering the manpower by automating stuff and allow people to play along.
I'm pretty sure thats the sort of thing Red Hat is internally working on as part of lauching Fedora Extras. No one is going to argue with you that fedora.us's infrastructure has been lacking. Its a catch-22 really. If Red Hat had not chosen to merge fedora.us into an official Fedora Extras I think more effort would have been made to extend fedora.us's infrastructure. But because Red Hat has been working to prepare a new infrastructure for Extras there has been considerable debate about the usefulness of building up fedora.us's infrastructure in the meantime just to scrap it. Hindsight is 20/20... i doubt few people inside Red Hat or inside fedora.us leadership thought it would take as long as it has to get Red Hat's internal build system ready for the merger. In fact... someone has promised me to eat a shoe on national television if i can find a station willing to broadcast it.. because Extras was not ready in time for fc3 release. C'mon... whose going to willingly promise me to eat their shoe unless they seriously thought everything would be ready in time.
The day I do that, the QA queue of fedora.us will be 4x as big as it is now and it will take a long time for these packages to even hit the repository (if ever).
I will fully submit to you that the QA process as originally concieved is not the the long term solution. And in fact changes have already been made to relieve the QA burden for "trusted" packagers inside the fedora.us process....the evolution of the QA concept will continue... and people who are committed to using the process will have a much more qualified say in its evolution than those people who refuse to work with it, even when its grosquely malformed. The QA pre-release process is a work in progress... but the concept itself is useful for many reasons even if the exact implementation details and balance are not completely worked out. And I tell you this... I highly doubt the concept is going to dissappear completely in Fedora Extras. Peer review and QA will be one of the strongest mechanisms for new packagers to gain trust in the Extras process and build system... there is no other way to build a community process.
I wouldn't be able to update or add new packages because of the overhead that is demanded of me by the policies and procedures that currently lack any automation or infrastructure.
Again... I believe this is exactly the things Red Hat is aiming to solve with its infrastructure. And because Red Hat is working on it internally.. there is has been a reluctance to duplicate that effort at fedora.us just to scrap fedora.us when Red Hat is ready for the merger. Take a step back then take two step forward and you are doing the fedora infrastructure shuffle.
There is a reason why there still aren't any FC3 packages. I don't want to pressure Red Hat and I think this thread is not worth everyone's time spend. But don't give the impression that I'm not willing to cooperate or that it is possible to add packages today, because it simply is NOT.
I know its not. But i will be frank with you. I am under the distinct impression... that your other pressures to keep packages trees for older rhl and rhel releases greatly impacts how far you are willing to bend to be able to contribute to an official Fedora Extras tree when it does open up. There is no malice in my statement. I fully understand that as a 3rd party repository maintainer you have your own established userbase to consider. But I'm not sure how far Red Hat's infrastructure and fedora extras policy will be able to accomedate the other constraints you impose on yourself by supporting all those other trees with your packages.
First work on the infrastructure before you add voluntary manpower, otherwise you're effectively wasting manpower and potentially ruining a community project. It currently does not scale, tools are missing.
Tools are missing... Red Hat has internal effort to work on this.
Look, we've effectively zero'd all duplication effort by simplying sharing and merging our SPEC files and SPEC development. 4 repositories now are no longer developing their own stuff.
thats 4... out of what.... 3000. I refuse to limit discussion to the big repos. there are many many smaller repos out there that deserve to be included in any general discussion of costs and duplication. And i will argue that whatever gains you get from sharing common spec files... is amplified by sharing a common build system competely. And the idea of "Fedora Collections" is a future path that demands cetralized package building... as the basis for media set generation.
-jef
On Tue, 30 Nov 2004, Jeff Spaleta wrote:
On Wed, 1 Dec 2004 01:53:30 +0100 (CET), Dag Wieers dag@wieers.com wrote:
Why don't you start lowering the manpower by automating stuff and allow people to play along.
I'm pretty sure thats the sort of thing Red Hat is internally working on as part of lauching Fedora Extras. No one is going to argue with you that fedora.us's infrastructure has been lacking. Its a catch-22 really. If Red Hat had not chosen to merge fedora.us into an official Fedora Extras I think more effort would have been made to extend fedora.us's infrastructure. But because Red Hat has been working to prepare a new infrastructure for Extras there has been considerable debate about the usefulness of building up fedora.us's infrastructure in the meantime just to scrap it. Hindsight is 20/20... i doubt few people inside Red Hat or inside fedora.us leadership thought it would take as long as it has to get Red Hat's internal build system ready for the merger. In fact... someone has promised me to eat a shoe on national television if i can find a station willing to broadcast it.. because Extras was not ready in time for fc3 release. C'mon... whose going to willingly promise me to eat their shoe unless they seriously thought everything would be ready in time.
Jeff, let me simply add that I don't read these long paragraphs without any structure. But that's probably me.
The day I do that, the QA queue of fedora.us will be 4x as big as it is now and it will take a long time for these packages to even hit the repository (if ever).
I will fully submit to you that the QA process as originally concieved is not the the long term solution.
All fine and well, but I can't add my stuff today. That's what I said. (everything else you said was again hard to read or follow)
I wouldn't be able to update or add new packages because of the overhead that is demanded of me by the policies and procedures that currently lack any automation or infrastructure.
Again... I believe this is exactly the things Red Hat is aiming to solve with its infrastructure. And because Red Hat is working on it internally..
Fine, I don't mind. Call me when it's there and there are no technical or other limiting factors. I don't want to enforce my own processes or procedures and I'm available to discuss them. But if the same work takes much longer in overhead (and unautomated procedures) and requires more time of me, I don't think it should be applied to other volunteers as well. That would be wasting people's time, wouldn't it ?
There is a reason why there still aren't any FC3 packages. I don't want to pressure Red Hat and I think this thread is not worth everyone's time spend. But don't give the impression that I'm not willing to cooperate or that it is possible to add packages today, because it simply is NOT.
I know its not. But i will be frank with you. I am under the distinct impression... that your other pressures to keep packages trees for older rhl and rhel releases greatly impacts how far you are willing to bend to be able to contribute to an official Fedora Extras tree when it does open up. There is no malice in my statement. I fully understand that as a 3rd party repository maintainer you have your own established userbase to consider. But I'm not sure how far Red Hat's infrastructure and fedora extras policy will be able to accomedate the other constraints you impose on yourself by supporting all those other trees with your packages.
Actually, I bet you have little idea how it works. But you're right, I'm not considering duplicating _my_ effort if Fedora Extras does no consider allowing RHEL2.1 or RHEL3 tags.
If it means forking, the overhead is forced on me, where today there isn't any overhead. But I do believe you have little idea how my stuff technically works now, so I'm sure you're overestimating the time spend to provide backward compatibility.
It's less than 5%, if it does not build on older stuff and it requires replacing core stuff, it's no longer supported for an older distribution. Simple as that. Most of the backward compatibility grows in time, if something used to build and does not longer, a quick check will reveal whether it's fixable or not.
BTW to build my packages, the only thing required is to add 1 simple define to your build process. I'm not demanding fedora.us starts building for everything I'm building. Hell no.
First work on the infrastructure before you add voluntary manpower, otherwise you're effectively wasting manpower and potentially ruining a community project. It currently does not scale, tools are missing.
Tools are missing... Red Hat has internal effort to work on this.
That's fine. Call me when it's there. Don't talk about the future as if it is present. I'm sure my userbase would complain anyway if I waited.
Look, we've effectively zero'd all duplication effort by simplying sharing and merging our SPEC files and SPEC development. 4 repositories now are no longer developing their own stuff.
thats 4... out of what.... 3000. I refuse to limit discussion to the big repos. there are many many smaller repos out there that deserve to be included in any general discussion of costs and duplication. And i will argue that whatever gains you get from sharing common spec files... is amplified by sharing a common build system competely. And the idea of "Fedora Collections" is a future path that demands cetralized package building... as the basis for media set generation.
Actually Jeff, there are more repositories. 3000 is a little exagerated and I don't want to belittle the smaller repositories, in fact I would invite them to join RPMforge, when they feel they're ready or when we're ready to invite them.
BTW Those 4 repositories are spending a large part of the overall effort in Red Hat contrib packaging. A modest guess would be +40%, so if we're talking about real effort in total, I think it's a considerable gain.
The advantage is that their stuff will be build for RHEL2.1, RH7.3, RH9, RHEL3, FC1, FC2 and FC3. For several architectures, i386, x86_64, alpha, ppc, sparc. And we may add support for other distributions like SuSE or Conectiva with little overhead and even less duplication effort than you've been talking about so noisely.
So yes, it's not limited to Fedora. And I'd rather not exclude myself from Fedora Extras if it's not necessary. I think it's a mutual advantage to work together, at least if the burden is not on me. (Evenly it doesn't have to be on Fedora Extras either, as my stuff is already Fedora compatible in essence)
Remember that I'm not necessarily duplicating effort here, in a lot of cases fedora.us has been duplicating effort since my stuff was already openly available and they've chosen to ignore that. The interfacing simply was never there.
As you can see this has nothing to do with emotions or egos. I'm sure some people want you to believe that and I'm sure that if you believe that, you can see the signs everywhere. Especially in my signature !
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [All I want is a kind word, a warm bed and unlimited power.]
On Wed, 1 Dec 2004 02:47:14 +0100 (CET), Dag Wieers dag@wieers.com wrote:
Jeff, let me simply add that I don't read these long paragraphs without any structure. But that's probably me.
That's unfortunate. I guess I'll stop trying to write comprhensive responses to you until i write a script to turn my prose into well formated python code.
Actually, I bet you have little idea how it works. But you're right, I'm not considering duplicating _my_ effort if Fedora Extras does no consider allowing RHEL2.1 or RHEL3 tags.
As long as we are clear on where your tight constraints are. Are there any other tight constraints that would prevent you from contributing to the centralized process you want to air now for the record?
If it means forking, the overhead is forced on me, where today there isn't any overhead. But I do believe you have little idea how my stuff technically works now, so I'm sure you're overestimating the time spend to provide backward compatibility.
I make no effort to estimate how much effort you spend inside your own build system. I am concerned about how much effort Red Hat has to expend to accomedate your external contraints and how far your external contraints allow you to bend to work inside what fedora process whatever that publicly communicated process is.
That's fine. Call me when it's there. Don't talk about the future as if it is present. I'm sure my userbase would complain anyway if I waited.
Actually Jeff, there are more repositories. 3000 is a little exagerated and I don't want to belittle the smaller repositories, in fact I would invite them to join RPMforge, when they feel they're ready or when we're ready to invite them.
"When we are ready to invite them"... thats an interesting sentence on the heels on your request for me not to talk about the future as if its the present. I'm more than willing to play the part of kettle if you are willing to play the role of pot.
RPMforge is there to address the needs of a small group of established 3rd party repos, it will not scale to accomedate all packagers and all repos. I feel RPMforge does more to protect the established brandname status of established repositories than it does to provide a community framework for future packagers and initatives. I'm not exactly happy with the idea of encouraging as Fedora policy a 'community' of packagers that will not scale to include individuals who have skill but not their own infrastructure for distribution.
BTW Those 4 repositories are spending a large part of the overall effort in Red Hat contrib packaging. A modest guess would be +40%, so if we're talking about real effort in total, I think it's a considerable gain.
No one argues that right now, today, 3rd party repositories are not playing a significant role. But what I argue is, centralization into one repository has long term advantages for the Fedora project. And I would also argue if Red Hat had thought ahead and provided a framework for this sort of crap during rhl.. we wouldn't have large 3rd party repos. I place ALL the blame on Red Hat for leaving a void and not fostering a centralized packaging network earlier on.
The advantage is that their stuff will be build for RHEL2.1, RH7.3, RH9, RHEL3, FC1, FC2 and FC3. For several architectures, i386, x86_64, alpha, ppc, sparc. And we may add support for other distributions like SuSE or Conectiva with little overhead and even less duplication effort than you've been talking about so noisely.
If providing cross distribution packages and EOL'd distribution packages is the goal you seek.. then by all means... use your resources as you see fit. But whether or not these goals are considered compatible with Fedora project policy and long term plans remains to be seen. I believe tying package building as closely to each distribution's own process as possible is a better use of resources and provides better integration with each distribution.
Personally from your statements, I get the feeling that the cost of any extra overhead to have your packages appear in the Fedora build system will be too much for you to be willing to contribute to a centralized process that lays the ground work for an expanded and more flexible Fedora project. If that is the case, I will simply leave you with good luck to you and your efforts. But please, if you do decide not to contribute to Fedora Extras lets make a clean break of it. I'm not thrilled about the idea of having this sort of conversation again 6 months from now with someone who isn't really invested in trying to work within the established framework (even if that framework is fubared.. i expected a good faith effort from loyal opposition to work within the system). I'm trying to give you the benefit of the doubt now, hoping to learn what the critical issue are that would keep you from attempting to contribute to an official Fedora Extras.
-jef
On Tue, 30 Nov 2004, Jeff Spaleta wrote:
On Wed, 1 Dec 2004 02:47:14 +0100 (CET), Dag Wieers dag@wieers.com wrote:
Actually, I bet you have little idea how it works. But you're right, I'm not considering duplicating _my_ effort if Fedora Extras does no consider allowing RHEL2.1 or RHEL3 tags.
As long as we are clear on where your tight constraints are. Are there any other tight constraints that would prevent you from contributing to the centralized process you want to air now for the record?
Well, I don't see them as constraints really. Quite the opposite, I'm now constraint to modify my SPEC files to only work for Fedora, while that constraint could easily be lifted with just a few agreements of a standard. A standard that would even benefit cross-fedora rebuilds from the same SPEC file with little effort.
BTW whatever in my proposed standard is unacceptable I'm willing to drop as long as the same functionality is there. With some RPM adjustements, already discussed with JBJ, it could even be incorporated with RPM.
And, Jef, I'm convinced that if this is not decided now, they will have a similar feature in a couple of years anyway. Because it's so simple and saves so much time that it's even strange there hasn't been an accepted standard already.
BTW Some Red Hat packages (like sendmail) used to have similar things included like we adopted, so it's not new and no rocket science either. It's just a standard way of working and a standard naming policy of macros.
If it means forking, the overhead is forced on me, where today there isn't any overhead. But I do believe you have little idea how my stuff technically works now, so I'm sure you're overestimating the time spend to provide backward compatibility.
I make no effort to estimate how much effort you spend inside your own build system. I am concerned about how much effort Red Hat has to expend to accomedate your external contraints and how far your external contraints allow you to bend to work inside what fedora process whatever that publicly communicated process is.
Well, that's fine than. I don't want to enforce any policies, I don't think I'm in a position to make demands anyway. But you asked for my concerns, I gave them, and that's that. If it is decided that it does not fit, no problem.
But don't say I'm the one duplicating effort and all that nonsense.
That's fine. Call me when it's there. Don't talk about the future as if it is present. I'm sure my userbase would complain anyway if I waited.
Actually Jeff, there are more repositories. 3000 is a little exagerated and I don't want to belittle the smaller repositories, in fact I would invite them to join RPMforge, when they feel they're ready or when we're ready to invite them.
"When we are ready to invite them"... thats an interesting sentence on the heels on your request for me not to talk about the future as if its the present. I'm more than willing to play the part of kettle if you are willing to play the role of pot.
Yes, that sentence means that we're not inviting everyone right now because it would not scale and mark the end of the project sooner than later. I thought we handled that ?
RPMforge is there to address the needs of a small group of established 3rd party repos, it will not scale to accomedate all packagers and all repos. I feel RPMforge does more to protect the established brandname status of established repositories than it does to provide a community framework for future packagers and initatives. I'm not exactly happy with the idea of encouraging as Fedora policy a 'community' of packagers that will not scale to include individuals who have skill but not their own infrastructure for distribution.
No, it's common sense. I admit we don't scale and frankly I don't think allowing everyone to add things is a very good idea overall. I'm sure Fedora Extras will have the same policy. Mark my words, everyone can help out, but not everyone will have commit access or be able to build packages. Common sense, Jef.
If you argue we should enter into the same mess (let's call it that because my English does not have a softer word) as fedora.us, which is also NOT scalable, we are not going to do that.
I rather explain to people why at this point we lack the tools and infrastructure to scale, they're free to help build those tools and infrastructure and if they've proven that they can work with us with limited overhead no problem. Existing packagers can do that, that scales.
I'm sure you understand all that very well. It's sad that we can't allow everyone to be involved in the actual building, but they can do a whole lot providing feedback, bugfixes, improvements and even contributing SPEC files. And if the time's right they can join if they're committed.
But that's reality, no beating around the bush here.
BTW Those 4 repositories are spending a large part of the overall effort in Red Hat contrib packaging. A modest guess would be +40%, so if we're talking about real effort in total, I think it's a considerable gain.
No one argues that right now, today, 3rd party repositories are not playing a significant role.
If you say so :) You'd be surprised.
The advantage is that their stuff will be build for RHEL2.1, RH7.3, RH9, RHEL3, FC1, FC2 and FC3. For several architectures, i386, x86_64, alpha, ppc, sparc. And we may add support for other distributions like SuSE or Conectiva with little overhead and even less duplication effort than you've been talking about so noisely.
If providing cross distribution packages and EOL'd distribution packages is the goal you seek.. then by all means... use your resources as you see fit. But whether or not these goals are considered compatible with Fedora project policy and long term plans remains to be seen. I believe tying package building as closely to each distribution's own process as possible is a better use of resources and provides better integration with each distribution.
Again, I never said that Fedora Extras view should be to do the same thing as I am doing wrt building for multiple distributions. Where do you get that from ?
But they should allow the extra information inside the SPEC file so that I do not have to fork my stuff to have a special edition for fedora.us.
If not, they are limiting me (and the contributed SPEC files), not the other way around. And in that case it probably has to do with control and power instead of community and sharing.
To me it's clear you don't have a clue what I'm talking about technically and I think it makes no sense to discuss this any further. We're not getting anywhere.
Personally from your statements, I get the feeling that the cost of any extra overhead to have your packages appear in the Fedora build system will be too much for you to be willing to contribute to a centralized process that lays the ground work for an expanded and more flexible Fedora project.
How can you know ? We don't know the Fedora Extras process and what we discussed until now was about the terminated fedora.us project.
Again if you would have any clue to what is necessary to build our SPEC files in another build system, you wouldn't be exagerating the effort here and now. You have the same flexibility to fine-tune to a distribution and the cross distribution stuff is more about creating communities around individual packages between distributions, than about building exactly the same package on all distribution. If that's what you think, broaden the view.
If that is the case, I will simply leave you with good luck to you and your efforts. But please, if you do decide not to contribute to Fedora Extras lets make a clean break of it. I'm not thrilled about the idea of having this sort of conversation again 6 months from now with someone who isn't really invested in trying to work within the established framework (even if that framework is fubared..
Sorry, but I did not start this thread and I'm only responding to some of the things that popped up and that either were wrong or misguided. And most of the confusion that people have comes from the fedora.us document in the first place and the lack of information about Fedora Extras.
Implying that I'm not willing to work together (what you've done repeatedly now) is not really nice though.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Wed, 1 Dec 2004 05:54:43 +0100 (CET), Dag Wieers dag@wieers.com wrote:
Implying that I'm not willing to work together (what you've done repeatedly now) is not really nice though.
I have not meant imply that you are unwilling to contribute under any circumstances. I'm sure if Fedora Extra's initial policy was exactly what you wanted you would contribute. What I am concerned about is trying to find out exactly under which conditions you are and are not willing to contribute. What would be blocking issues and what are issues that you can compromise over initially and work towards resolution inside the contributor process. From where I stand I'm not sure Fedora Extras as its initial policy will be laid out will be compatible with your personal desire to see a zero overhead solution, and I'm not sure how much overhead you are willing to put up with. If there is a failing here, its my personally failing to understand with accuracy the tenancy of your desire to be invovled.
-jef"pretty sure he's never said anything about being nice"spaleta
On Wed, 1 Dec 2004, Jeff Spaleta wrote:
On Wed, 1 Dec 2004 05:54:43 +0100 (CET), Dag Wieers dag@wieers.com wrote:
Implying that I'm not willing to work together (what you've done repeatedly now) is not really nice though.
I have not meant imply that you are unwilling to contribute under any circumstances. I'm sure if Fedora Extra's initial policy was exactly what you wanted you would contribute. What I am concerned about is trying to find out exactly under which conditions you are and are not willing to contribute. What would be blocking issues and what are issues that you can compromise over initially and work towards resolution inside the contributor process.
I thought I've been pretty clear about that. What's missing is information about Fedora Extras to put the pieces together.
From where I stand I'm not sure Fedora Extras as its initial policy will be laid out will be compatible with your personal desire to see a zero overhead solution, and I'm not sure how much overhead you are willing to put up with. If there is a failing here, its my personally failing to understand with accuracy the tenancy of your desire to be invovled.
Fair enough. It seems you have some inside information that I don't to draw such conclusions. I'll simply have to wait (proceed with what we're doing) and see.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Wednesday 01 December 2004 06:22, Jeff Spaleta wrote:
On Wed, 1 Dec 2004 05:54:43 +0100 (CET), Dag Wieers dag@wieers.com wrote:
Implying that I'm not willing to work together (what you've done repeatedly now) is not really nice though.
I have not meant imply that you are unwilling to contribute under any circumstances. I'm sure if Fedora Extra's initial policy was exactly what you wanted you would contribute. What I am concerned about is trying to find out exactly under which conditions you are and are not willing to contribute. What would be blocking issues and what are issues that you can compromise over initially and work towards resolution inside the contributor process.
Hello Jef,
A first problem in the contributor process in my opinion: there's no information at all about the new 'Fedora Extras buildsystem'. The build system will be open source i guess, so why can't the development be a bit more visible/open for people who are interested? For example why not make those (maybe unfinished) scripts and programs available in a public cvs or subversion repository?
Probably after some weeks/months we'll get a mail "hey it's ready" and there has been no input from people who will use it. Only then we'll get information about the possibilities and constraints of the build system. Why isn't this possible earlier?
I don't expect documentation or immediate answers to all questions, but simply making the source visible so the future users can look at it and test it on their own machines and maybe give valuable feedback and point at bugs.. i would really appreciate that. Then we can also track progress so nobody at Red Hat has to loose time on writing status mails.
kind regards, Dries Verachtert
On Wed, 2004-12-01 at 11:20 +0100, Dries Verachtert wrote:
Probably after some weeks/months we'll get a mail "hey it's ready" and there has been no input from people who will use it. Only then we'll get information about the possibilities and constraints of the build system. Why isn't this possible earlier?
I don't expect documentation or immediate answers to all questions, but simply making the source visible so the future users can look at it and test it on their own machines and maybe give valuable feedback and point at bugs.. i would really appreciate that. Then we can also track progress so nobody at Red Hat has to loose time on writing status mails.
Well put!
Red Hat has its head firmly lodged in its back-side on this issue. Here are people (obviously *competent* people) just itching to help out and they're excluded by some asinine policy that seems to be "we want a community but we can't tell you anything because you don't have an @redhat.com address".
What *possible* good can come from this approach?
Ed
On Wed, 1 Dec 2004 11:20:11 +0100, Dries Verachtert dries@ulyssis.org wrote:
On Wednesday 01 December 2004 06:22, Jeff Spaleta wrote: A first problem in the contributor process in my opinion: there's no information at all about the new 'Fedora Extras buildsystem'. The build system will be open source i guess, so why can't the development be a bit more visible/open for people who are interested? For example why not make those (maybe unfinished) scripts and programs available in a public cvs or subversion repository?
From what I understand from post in appropriate mainglist archives
from the people working on this issue inside Red Hat.. my understanding is the new build system Red Hat putting together is to some extent related to the build system they have been using internally in the past. Without knowing what the code looks like myself, I would imagine they would have to make sure the code was cleaned of any sensitive comments or information. So to answer as to why there hasn't been anything seen is complicated by Red Hat internal issues that you and I will never get a full explanation for. Getting a public cvs server up and running that meets Red Hat's internal constraints has been the priority as communicated in the few posts from the leadership into the devel mailinglist over the past months.
Probably after some weeks/months we'll get a mail "hey it's ready" and there has been no input from people who will use it. Only then we'll get information about the possibilities and constraints of the build system. Why isn't this possible earlier?
Red Hat developers are using the new infrastructure as well, so to say no input from people is stretching the truth a bit. I doubt the people working on this internally think the system will be perfect on the day its open to contributors. But the decision has been made to work out Red Hat's internal issues first... and use the result of that internal discussion as the starting point for the contributor process. I'm sure over time the process will be refined based on the experience of contributors using the system. But let me stress, it is my belief that people attempting to use the process (even if its imperfect) in good faith will be heard more clearly than those who stand outside the process waiting for the process to be perfect for them.
-jef
On Wed, 1 Dec 2004, Jeff Spaleta wrote:
But let me stress, it is my belief that people attempting to use the process (even if its imperfect) in good faith will be heard more clearly than those who stand outside the process waiting for the process to be perfect for them.
Jef, there is no process ! So you can't stand inside or outside, or do anything else than wait. Stop implying things, please.
I'm sure it all fits together inside your head though.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Wed, 1 Dec 2004 21:03:25 +0100 (CET), Dag Wieers dag@wieers.com wrote:
I'm sure it all fits together inside your head though.
And quite easily too. There's enough room in here for multiple universes and an olympic sized pool.
-jef"apologizes to the 1/3 of the world's population that has never seen the sun because it's been blocked out by my huge huge head"spaleta
On Tue, 2004-11-30 at 20:17 -0500, Jeff Spaleta wrote:
for the merger. In fact... someone has promised me to eat a shoe on national television if i can find a station willing to broadcast it.. because Extras was not ready in time for fc3 release. C'mon... whose going to willingly promise me to eat their shoe unless they seriously thought everything would be ready in time.
Hi folks,
I've been following this thread and am very glad for the commentary-- particularly from Jeff and Dag. I'm one of those occasional packagers who is hoping to get a few (very few) things into Fedora Extras. And I'm disappointed and confused by the lack of messages from the folks creating Fedora Extras.
I realize that supplying ETAs is hard. Thats fine. But could somebody who knows whats going on at least provide a few words about the status and what we can eventually expect? And maybe do it once a week or once every two weeks? It would be nice to get an idea (even if its just a rough sketch) of whats going on.
IMHO Red Hat is doing a very half-baked job of increasing the number of viable packagers. Their Fedora Extras setup is confusing, cumbersome, tardy, and the folks running it seem mighty reticent for people supposedly trying to "build a community". Perhaps this newer and more open Fedora Extras will be a big improvement.
Heres hoping that it is.
Ed
Tirsdag 30 november 2004 09:06 skrev Jeff Spaleta:
If an individual maintainer can no longer package in a centralized build system... a volunteer does not need to try to duplicate any of the build infrastructure to come forward and maintain the packages that were orphaned.
It is of course an interesting problem you mention here. 6 years ago we converted all our computers to redhat linux, we had a mixture of suns and intel machines. (I was chairman of a math dept. at the time) Then we were left high and dry because red hat no longer supported redhat on suns. Later redhat gave up on the standard series we were following, the redhat series. We used to buy for around $300-500 pr year from redhat, less after they no longer supported the sun machines. After a while you do of course develop some expertise dealing with a specific system, so we have more or less decided to go along with fedora. We would not be able to afford rhel.
So it is indeed an issue if something you rely on disappears, but since redhat has done that to us at least twice and more if you count giving up support for things like mp3, I do not see the risk from third part repositories being any bigger than relying on redhat in particular on the fedora core system.
Erik
Hi
since redhat
has done that to us at least twice and more if you count giving up support for things like mp3, I do not see the risk from third part repositories being any bigger than relying on redhat in particular on the fedora core system.
Redhat being a US based distro, there is no way it could have continued supporting mp3 stuff. users dont have a problem with using it. you just cannot *distribute* it. if you cant stick with RHEL due to price centos(centos.org) might be a valid alternative...
On Tue, 30 Nov 2004, Erik Kjær Pedersen wrote:
Tirsdag 30 november 2004 09:06 skrev Jeff Spaleta:
If an individual maintainer can no longer package in a centralized build system... a volunteer does not need to try to duplicate any of the build infrastructure to come forward and maintain the packages that were orphaned.
It is of course an interesting problem you mention here. 6 years ago we converted all our computers to redhat linux, we had a mixture of suns and intel machines. (I was chairman of a math dept. at the time) Then we were left high and dry because red hat no longer supported redhat on suns.
Well, it won't help now, but there's Aurora Linux and our packages are build for Aurora/sparc. We also welcome anyone willing to build our SPEC files for another distribution/architecture.
And one of the missing pieces currently is an easy tool that allows you to kick off a build-environment and allows you to manually build a package. But more importantly, kick off a build-environment that automatically starts building a set of SPEC files and everything that gets updated in subversion.
The goal is that organisations, individuals and vendors can rebuild whatever matters to them and report failures and improvements to us without the need of forking. Such a tool will more easily allow anyone to create their own packages, verify integrity, with the proper QA tool enforces policies and contribute a package that needs little QA and if they like add their own branding.
Much like Gentoo, if you just want to experiment with building and are interested in refining the packages from the base up.
Of course, it is far from complete currently.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Sun, 28 Nov 2004 11:44:26 -1000, Chris Stark wrote:
I don't like the tone of their page. If Fedora Core is supposed to be a community project, there should not be a centralized QA process for "acceptible" packages. The community will decide what works by process of natural selection.
They do, they do. It's people from the community, who judge whether a package will be included or not. But this is done prior to release. Else a package or upgrade (!), which is not good enough, would need to be removed after release when users criticize the packagers for releasing something which was not ready.
And *you* could approve packages, too: http://tinyurl.com/4nxrw Do any of the submitted packages interest you? Or are you not courageous enough to take responsibility for approving a package? No, this is not about packaging something up and letting the community find out whether it breaks something. This is about pre-release QA. Packagers, who maintain their packages painstakingly, don't depend on as much as QA as others.
No, they shouldn't be responsible for system stability if a 3rd party package breaks the system. Disclaiming responsibility is fine (and probably the appropraite thing to do). But undermining other repos by using conflicting naming systems IS "Microsoft-ish" (and thus utterly reprehensible) and they should be ashamed of themselves.
Where is this conflicting naming scheme? Fedora.us' package naming guidelines are documented for a very long time, unchanged. They are the result of long mailing-list dicussions. What about the 3rd party repositories?
On Mon, Nov 29, 2004 at 10:11:57AM +0100, Michael Schwendt wrote:
On Sun, 28 Nov 2004 11:44:26 -1000, Chris Stark wrote:
probably the appropraite thing to do). But undermining other repos by using conflicting naming systems IS "Microsoft-ish" (and thus utterly reprehensible) and they should be ashamed of themselves.
Where is this conflicting naming scheme? Fedora.us' package naming guidelines are documented for a very long time, unchanged. They are the result of long mailing-list dicussions. What about the 3rd party repositories?
You yourself wrote a mail only a few weeks before, where you even layed out the timescale of the conflicting naming scheme.
Michael's anmesia http://www.redhat.com/archives/fedora-list/2004-November/msg00814.html
(One of) Axel's pleas for interrepo versioning scheme http://www.fedora.us/pipermail/fedora-devel/2003-February/000216.html | IMHO one should very carefully reconsider naming | conventions. Instead of trying to overcome version/release ordering | scheme problems by obfuscating them, one should try to specify a | versioning scheme, that will allow interoperation of repositories.
One of the rejections: http://www.fedora.us/pipermail/fedora-devel/2003-March/000516.html | > A repository identification string in the middle of a release tag | > makes it also very hard to have repository coordination (no ... not | > that sword again ... ;) | | I am still against repository coordination because that implies more | delay in repository building. I sincerely believe that after we | have our specifications done, several packagers can quickly convert | all repositories into Fedora and that would be the end of it.
Matthew Miller wrote:
On Sun, Nov 28, 2004 at 04:11:25PM -0500, William M. Quarles wrote:
Join us or we'll start reproducing your software in your place anyways. Does this not scream arrogance, bureacracy, and monopoly to anybody else? Does this not seem very Microsoft-ish? Can you actually expect
There's been a lot of discussion about this. The points the page makes are real, and declaring their answer "Microsoft-ish" isn't constructive. Do you have an alternate *solution*?
I do recognize their points, but unfortunately you have failed to recognize mine. In case you didn't notice, my message did point out an alternate *solution*.
William
On Sun, Nov 28, 2004 at 05:05:23PM -0500, William M. Quarles wrote:
There's been a lot of discussion about this. The points the page makes are real, and declaring their answer "Microsoft-ish" isn't constructive. Do you have an alternate *solution*?
I do recognize their points, but unfortunately you have failed to recognize mine. In case you didn't notice, my message did point out an alternate *solution*.
Making Fedora Extras a very tiny "outer" core of library packages and not try to provide a wide base of packages that all work nicely together? That's more "dropping having Fedora Extras" than it is solving the problem of repository conflicts.
Matthew Miller wrote:
On Sun, Nov 28, 2004 at 05:05:23PM -0500, William M. Quarles wrote:
There's been a lot of discussion about this. The points the page makes are real, and declaring their answer "Microsoft-ish" isn't constructive. Do you have an alternate *solution*?
I do recognize their points, but unfortunately you have failed to recognize mine. In case you didn't notice, my message did point out an alternate *solution*.
Making Fedora Extras a very tiny "outer" core of library packages and not try to provide a wide base of packages that all work nicely together? That's more "dropping having Fedora Extras" than it is solving the problem of repository conflicts.
Uh, no it isn't. (To go with my previous example) where I get one version of Xine vs. some different version Xine doesn't really matter because other packages aren't dependent on it. However, all of the underlying libraries are carried by multiple repositories and they are used by multiple programs. If Fedora Core does not have any applications using those libraries (or other programs that have dependencies but they aren't really used in Fedora Core), then obviously they should not be a part of Fedora Core, and thus those are the types of things that Fedora Extras should carry. Anything more would become some nightmare of a too big community, like the Roman Empire.
---- Peace, William
On Mon, 2004-11-29 at 14:07 -0500, William M. Quarles wrote:
Matthew Miller wrote:
On Sun, Nov 28, 2004 at 05:05:23PM -0500, William M. Quarles wrote:
There's been a lot of discussion about this. The points the page makes are real, and declaring their answer "Microsoft-ish" isn't constructive. Do you have an alternate *solution*?
I do recognize their points, but unfortunately you have failed to recognize mine. In case you didn't notice, my message did point out an alternate *solution*.
Making Fedora Extras a very tiny "outer" core of library packages and not try to provide a wide base of packages that all work nicely together? That's more "dropping having Fedora Extras" than it is solving the problem of repository conflicts.
Uh, no it isn't. (To go with my previous example) where I get one version of Xine vs. some different version Xine doesn't really matter because other packages aren't dependent on it. However, all of the underlying libraries are carried by multiple repositories and they are used by multiple programs. If Fedora Core does not have any applications using those libraries (or other programs that have dependencies but they aren't really used in Fedora Core), then obviously they should not be a part of Fedora Core, and thus those are the types of things that Fedora Extras should carry. Anything more would become some nightmare of a too big community, like the Roman Empire.
In theory you might be right. However, using the name *Fedora Extras* does not make them the best source for packages, and as others have noted, some of their stuff has been known to break core packages.
I encountered this myself when trying to do an update with fedora.us as an available repository and it refused because several (20 or more) required a couple of libraries that fedora.us packages were trying to replace. Removing fedora.us from the available repositories fixed the dependency problems.
If they were providing the proper QA and verifying that nothing they did would break the core software then their site would be more attractive. I do not use them and do not miss them.
Matthew Miller wrote:
On Sun, Nov 28, 2004 at 04:11:25PM -0500, William M. Quarles wrote:
Join us or we'll start reproducing your software in your place anyways. Does this not scream arrogance, bureacracy, and monopoly to anybody else? Does this not seem very Microsoft-ish? Can you actually expect
There's been a lot of discussion about this. The points the page makes are real, and declaring their answer "Microsoft-ish" isn't constructive. Do you have an alternate *solution*?
The problem is Fedora is it's not moving fast enough and adding enough packages. The fact that 3-4 people can deliver what they can't is preposterous.
They really need to take a hard look at this. I should;d not have to go to kde-redhat, Dag Wieers, FreshRPMS and NewRPMs get to software (which is compiled for Fedora) for Fedora. I should be getting it from Fedora......
Well, I would if they offered it....
In the meantime if Fedora is being blatant about ensuring their incompatibility with the above named repositories (as many accuse them of being) then they need to stop that nonsense too.
Fedora should encourage, not discourage users.
Honestly, the only reason I'm not using SUSE right now is because Fedora is the only distro I could find that managed a release with the latest GNOME and KDE. Most distro can mange one but not the other (for some reason).
On a related note, I'm an oddball who actually likes *both* GNOME and KDE..
Scott
On Sun, 2004-11-28 at 16:39 -0700, Scott wrote:
Matthew Miller wrote:
On Sun, Nov 28, 2004 at 04:11:25PM -0500, William M. Quarles wrote:
Join us or we'll start reproducing your software in your place anyways. Does this not scream arrogance, bureacracy, and monopoly to anybody else? Does this not seem very Microsoft-ish? Can you actually expect
There's been a lot of discussion about this. The points the page makes are real, and declaring their answer "Microsoft-ish" isn't constructive. Do you have an alternate *solution*?
The problem is Fedora is it's not moving fast enough and adding enough packages. The fact that 3-4 people can deliver what they can't is preposterous.
They really need to take a hard look at this. I should;d not have to go to kde-redhat, Dag Wieers, FreshRPMS and NewRPMs get to software (which is compiled for Fedora) for Fedora. I should be getting it from Fedora......
Well, I would if they offered it....
In the meantime if Fedora is being blatant about ensuring their incompatibility with the above named repositories (as many accuse them of being) then they need to stop that nonsense too.
And you have not kept up with the notes on the incompatibilities of some repositories?
AFAIK all the packagers are creating packages that work with fedora. However, packages from some sites (dag, et al. and fedora.us, et al) are not compatible with the same packages or dependencies from the other set of sites. Certain mixes of packages break when gotten from incompatible sites.
If you have been following this list in the last few weeks you would know where that problem lies, and not blame that on fedora.
As I see it, the packagers in charge of fedora.us (aka fedora-extras) refuse to try and build packages that are cross compatible in spite of Dag's attempts to work with them and make packages that "just work" regardless of what site they came from and what site mixture is used.
Fedora should encourage, not discourage users.
Honestly, the only reason I'm not using SUSE right now is because Fedora is the only distro I could find that managed a release with the latest GNOME and KDE. Most distro can mange one but not the other (for some reason).
On a related note, I'm an oddball who actually likes *both* GNOME and KDE..
Scott
On Mon, 2004-11-29 at 01:14 -0600, Jeff Vian wrote:
If you have been following this list in the last few weeks you would know where that problem lies, and not blame that on fedora.
The reasons are technical ones.
As I see it, the packagers in charge of fedora.us (aka fedora-extras)
Fedora.US != Fedora.Extras.
Fedora.US hosts and built Fedora-Extras for FC1/FC2.
Fedora Extras for FC3 is conducted by RH and supposed to be hosted by RH.
refuse to try and build packages that are cross compatible
"Refuse" is he wrong wording. It's technically impossible to be compatible with arbitrary repositories containing competing packages, so at least I don't even try to spend/waste time on trying to be compatible.
in spite of Dag's attempts to work with them and make packages that "just work" regardless of what site they came from and what site mixture is used.
Such attempts can only work in special cases at one point in time. In general and in longer terms, they are doomed to fail.
Ralf
On Mon, 29 Nov 2004, Ralf Corsepius wrote:
On Mon, 2004-11-29 at 01:14 -0600, Jeff Vian wrote:
refuse to try and build packages that are cross compatible
"Refuse" is he wrong wording. It's technically impossible to be compatible with arbitrary repositories containing competing packages, so at least I don't even try to spend/waste time on trying to be compatible.
Ralf, it's not impossible. There was a time, when fedora.us did not exist, when there were a few repositories that did not know about each other and did their own thing. At some point it was clear that there was too much overlap and it made sense to at least make some policies and standars and when things break to work together to fix it.
The result is here today, all major repositories (kde-redhat, freshrpms, planetccrma, atrpms, dries, dag, ...) they are all compatible with a minimum of effort. Sure from time to time there's something that conflicted either due to an oversight or miscommunication, in each case it was fixed within a few hours and (at least if you used apt) would seldom lead to a system that was impossible to update.
All that is necessary is that when something new is released, you first look if it already exists. If it already exists talk the the 'authority' of that package and see what you would do different and what would cause incompatibilities.
But instead fedora.us releases stuff that already existed for almost 2 years in my repository and change package-names so that it breaks. Or releases packages that does not follow a naming-convention that was even discussed on the fedora.us mailinglist at the very beginning.
I hate to bring this up again, but these are examples where a minimum of effort would have helped a lot of Fedora users. And by refusing to even discuss this (see the RepositoryMixing document) there are now 2 camps, not 3, not 4, only 2. fedora.us and non-fedora.us. Some repositories manage to be compatible with both, some don't even bother anymore because of this policy.
For me there's no reason to be incompatible. In fact, by being incompatible my users are indirectly harmed as they are inable t use fedora.us or livna.org. (Mind you, if you stay away from these incompatible packages, you won't notice this).
in spite of Dag's attempts to work with them and make packages that "just work" regardless of what site they came from and what site mixture is used.
Such attempts can only work in special cases at one point in time. In general and in longer terms, they are doomed to fail.
How do you know ? If 2 years isn't a long term, then what is ? If you don't try, you will never know, right ?
But please explain to me why it is doomed to fail ?
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
Mandag 29 november 2004 03:05 skrev Dag Wieers:
For me there's no reason to be incompatible. In fact, by being incompatible my users are indirectly harmed as they are inable t use fedora.us or livna.org. (Mind you, if you stay away from these incompatible packages, you won't notice this).
This really makes me happy. I am using kde-redhat, dag and freshrpms, and it seems to work wondefully, there was a tiny issue with redhat-menus recently but that was solved very quickly. The only problem is that you have to repeat this on this list every so often so that people will know what kind of mixing to avoid
Erik
Erik Kjær Pedersen wrote:
Mandag 29 november 2004 03:05 skrev Dag Wieers:
For me there's no reason to be incompatible. In fact, by being incompatible my users are indirectly harmed as they are inable t use fedora.us or livna.org. (Mind you, if you stay away from these incompatible packages, you won't notice this).
This really makes me happy. I am using kde-redhat, dag and freshrpms, and it seems to work wondefully, there was a tiny issue with redhat-menus recently but that was solved very quickly. The only problem is that you have to repeat this on this list every so often so that people will know what kind of mixing to avoid
Erik
Ditto. I'm quite pleased myself.
Now I wonder why this stuff just "works" (and well) without a huge team of developers and QA people......
Erik Kjær Pedersen wrote:
Mandag 29 november 2004 03:05 skrev Dag Wieers:
For me there's no reason to be incompatible. In fact, by being incompatible my users are indirectly harmed as they are inable t use fedora.us or livna.org. (Mind you, if you stay away from these incompatible packages, you won't notice this).
This really makes me happy. I am using kde-redhat, dag and freshrpms, and it seems to work wondefully, there was a tiny issue with redhat-menus recently but that was solved very quickly. The only problem is that you have to repeat this on this list every so often so that people will know what kind of mixing to avoid
I use both Planet CCRMA and FreshRPMs for a year and a half. I've only had one legitimate conflict (it was last week), and I told Fernando at Planet and he's on it; but I don't think it actually ever prevented me from installing or running any other software, it just kept me from updating that particular package. He has also been working to coordinate with Matthias at FreshRPMs.
---- Peace, William
On Mon, 2004-11-29 at 08:33 +0100, Ralf Corsepius wrote:
On Mon, 2004-11-29 at 01:14 -0600, Jeff Vian wrote:
If you have been following this list in the last few weeks you would know where that problem lies, and not blame that on fedora.
The reasons are technical ones.
Exactly. Since Fedora is the OS core, the packagers have to match their core product. Regardless of which repository the package comes from it still has to work on the base OS.
As I see it, the packagers in charge of fedora.us (aka fedora-extras)
Fedora.US != Fedora.Extras.
Fedora.US hosts and built Fedora-Extras for FC1/FC2.
Fedora Extras for FC3 is conducted by RH and supposed to be hosted by RH.
refuse to try and build packages that are cross compatible
"Refuse" is he wrong wording. It's technically impossible to be compatible with arbitrary repositories containing competing packages, so at least I don't even try to spend/waste time on trying to be compatible.
As I read the mail between (I think) you and Dag recently it seemed a refusal to try. This, even though his proposal was reasonable as an approach to making it work, or at least standardizing the approach to providing consistent features/dependencies.
in spite of Dag's attempts to work with them and make packages that "just work" regardless of what site they came from and what site mixture is used.
Such attempts can only work in special cases at one point in time. In general and in longer terms, they are doomed to fail.
Ralf
They are only "doomed to fail" in the beginning if there is no reasoned attempt to find a solution. While the attempt may fail, a failure to try does not preordain an insoluble problem, it only prevents the attempt at a solution.
Dag's suggestion to find a way to write spec files that are smart enough to be flexible seems a start at making it work, as would consistent naming and contents of packages. Refusing to consider and try his suggestion, but instead saying "it won't work" seems to me a "refusal to try".
Refusal to make an attempt makes certain that incompatibilities WILL exist.
Jeff
On Mon, Nov 29, 2004 at 02:31:06AM -0600, Jeff Vian wrote:
On Mon, 2004-11-29 at 08:33 +0100, Ralf Corsepius wrote:
On Mon, 2004-11-29 at 01:14 -0600, Jeff Vian wrote:
As I see it, the packagers in charge of fedora.us (aka fedora-extras) refuse to try and build packages that are cross compatible
"Refuse" is he wrong wording. It's technically impossible to be compatible with arbitrary repositories containing competing packages, so at least I don't even try to spend/waste time on trying to be compatible.
You are right, the correct wording was "rejected cooperation":
http://lists.freshrpms.net/pipermail/freshrpms-list/2003-November/006430.htm... | I would assert that the alliances of 3rd party repositories that | have tried to form in the recent past are not sustainable in the | long term, for the same controversial reasons that fedora.us | rejected cooperation with those entities earlier this year.
Dag's suggestion to find a way to write spec files that are smart enough to be flexible seems a start at making it work, as would consistent naming and contents of packages. Refusing to consider and try his suggestion, but instead saying "it won't work" seems to me a "refusal to try".
Refusal to make an attempt makes certain that incompatibilities WILL exist.
Exactly the situation of spring 2003. See my other posts refreshing memories in this thread.
If the efforts to resists compatibility had been coined into such improving it, this thread would not exist.
And unfortunately there are still people sabotaging cooperation of fedora.us and the rest of the world from within fedora.us. I believe most of the current members of fedora.us are ready to switch off the non-mixing manifesto, but a (very) few black sheeps keep them from it.
On Mon, 29 Nov 2004 01:14:08 -0600, Jeff Vian wrote:
As I see it, the packagers in charge of fedora.us (aka fedora-extras) refuse to try and build packages that are cross compatible in spite of Dag's attempts to work with them
Where can I learn more about those attempts?
On Mon, 2004-11-29 at 09:35 +0100, Michael Schwendt wrote:
On Mon, 29 Nov 2004 01:14:08 -0600, Jeff Vian wrote:
As I see it, the packagers in charge of fedora.us (aka fedora-extras) refuse to try and build packages that are cross compatible in spite of Dag's attempts to work with them
Where can I learn more about those attempts?
This is part of one thread on the subject. http://www.redhat.com/archives/fedora-list/2004-November/msg00731.html
-- Fedora Core release 3 (Heidelberg) - Linux 2.6.9-1.681_FC3 loadavg: 1.05 1.13 1.14
On Mon, 29 Nov 2004 02:54:53 -0600, Jeff Vian wrote:
On Mon, 2004-11-29 at 09:35 +0100, Michael Schwendt wrote:
On Mon, 29 Nov 2004 01:14:08 -0600, Jeff Vian wrote:
As I see it, the packagers in charge of fedora.us (aka fedora-extras) refuse to try and build packages that are cross compatible in spite of Dag's attempts to work with them
Where can I learn more about those attempts?
This is part of one thread on the subject. http://www.redhat.com/archives/fedora-list/2004-November/msg00731.html
There have not been any attempts since the fedora.us preparation talks on fedora-devel@fedora.us till early 2003. So, this is beating a dead horse.
If you want cross compatibility,
* you agree on common package naming guidelines, * you don't use conflicting versioning schemes, * you don't upgrade eachother at all, * you play nice with Fedora Core as a common base, i.e. you don't upgrade Fedora Core, regardless of how minor the upgrade may be (fedora.us discontinued its separate and very small "patches" repository a year ago), * you agree on moving overlapping content into a common base repository (Fedora Core is a base, Fedora Extras is the next candidate), * you replicate common packages if need be, so feature set and versions are the same in every repository (rebuilding packages creates a dependency on multiple build environments), * you coordinate updates with the packagers of all affected dependencies (this creates a need for pre-release QA!), * you open up your development process.
Some items from the list would have been simple to do, though if you don't get people to agree on common versioning guidelines because of "explicit Epochs", everything is lost already. ;) Other items would not be feasible without a lot of overhead or without violating a repositories' goals. E.g. fedora.us is self-hosting except for its dependence on Fedora Core. Obviously, you can't have an open community project, with public pre-release QA policies, depend on packages which are published by an individual using a closed development process. Further, as soon as there are overlapping contents, either all repositories agree on using the same build and name-version-release of a package (which likely is too limiting for some repositories), or you no longer play nice with eachother.
On Mon, Nov 29, 2004 at 10:55:06AM +0100, Michael Schwendt wrote:
If you want cross compatibility,
[snip]
- you don't upgrade eachother at all,
I think this one is a problem. Which repositories get to be in the Cabal of Sites Which Can Block Everyone Else From Updating a Package?
On Sun, 28 Nov 2004 16:39:24 -0700, Scott wrote:
The problem is Fedora is it's not moving fast enough and adding enough packages. The fact that 3-4 people can deliver what they can't is preposterous.
You compare apples and oranges. Nobody has claimed that it would be easier to publish something in a system where you depend on QA from other developers. This has been beaten to death in older discussions. We have yet to see how official Fedora Extras will tackle the QA system.
And let me tell you one thing. Being a contributor at fedora.us, I've seen hundreds of packages from many different packagers. There are packagers which show that _they_ maintain the package and only need somebody's approval to get the package built and published. On the contrary, there are packagers who submit packages which don't even build or install. They give you the feeling that they don't care about a package enough. Some don't reply to reviews, making the time, which you have spent on testbuilding and reviewing a package, being wasted time. It's so easy to stay away. My respect to those who do the best with the existing infrastructure and policies and who ask questions in case something is unclear.
If "3-4 people" think they can create and maintain more than 1000 packages alone, let them do it. Thank them for doing it, if those packages seem to work fine for you. Although I don't see that all those packages are up-to-date or moving faster than packages in fedora.us.
Developing and maintaining packages takes time. And many developers either don't have enough of that time or don't have the time to maintain a package painstakingly and stay in close contact with the upstream project. So, unless additional contributors maintain additional packages, don't expect developers at fedora.us (or official Fedora Extras in the near future) to duplicate efforts and in order to increase quantity, try to provide all the packages found in 3rd party repositories.
Btw, just a week ago, incidentally, I was pointed to a package in Dag Wieers' repository, which he copied from my fedora.us package in early October, apparently saving him time. He has still not descended from his high horse to reply to my private mail. Though, on the same day he repaired the package silently already.
They really need to take a hard look at this.
Not fedora.us. Why should the active contributors at fedora.us see existing 3rd party repositories as competition and try to provide the same packages?
On Mon, 29 Nov 2004, Michael Schwendt wrote:
Btw, just a week ago, incidentally, I was pointed to a package in Dag Wieers' repository, which he copied from my fedora.us package in early October, apparently saving him time. He has still not descended from his high horse to reply to my private mail. Though, on the same day he repaired the package silently already.
Michael, don't start another war. I fixed the package because you were right and I did not answer your mail because it was another highly explosive one.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On Mon, 29 Nov 2004 09:41:32 +0100 (CET), Dag Wieers wrote:
On Mon, 29 Nov 2004, Michael Schwendt wrote:
Btw, just a week ago, incidentally, I was pointed to a package in Dag Wieers' repository, which he copied from my fedora.us package in early October, apparently saving him time. He has still not descended from his high horse to reply to my private mail. Though, on the same day he repaired the package silently already.
Michael, don't start another war.
I'm not aware of earlier ones started by me.
I fixed the package because you were right and I did not answer your mail because it was another highly explosive one.
Haha. Apparently, you opened it and read it and no explosives were set off. It would have been a nice move to reply to it. No need to comment on the certainly harmless text in it. I didn't even ask why you copied the package.
Since you claim to be unsubscribing from the list, I thought I'd send you this off-list as well, because you coming off as a word or phrase that I'll refrain from saying since it will only add to the flames.
Michael Schwendt wrote:
On Mon, 29 Nov 2004 09:41:32 +0100 (CET), Dag Wieers wrote:
Michael, don't start another war.
I'm not aware of earlier ones started by me.
I don't think he said that you did. He just pointed out that previous wars happened and not another one was needed, and implied that you were a very active participant in one or more of these wars.
I fixed the package because you were right and I did not answer your mail because it was another highly explosive one.
Haha. Apparently, you opened it and read it and no explosives were set off.
Funny. Not.
It would have been a nice move to reply to it. No need to comment on the certainly harmless text in it.
If he didn't comment on it then what kind of reply would you expect? An empty one? This is pretty absurd.
I didn't even ask why you copied the package.
Like I said on the list (but possibly you did not receive it): who cares? It's Free software.
And as I also said on that message:
(and here is your text)
Not fedora.us. Why should the active contributors at fedora.us see existing 3rd party repositories as competition and try to provide the same packages?
Hello, we aren't suggesting competition here! What have we been saying guys? "COOPERATION! COORDINATION!"
---- Peace, William
On Mon, 2004-11-29 at 09:41 +0100, Dag Wieers wrote:
On Mon, 29 Nov 2004, Michael Schwendt wrote:
Btw, just a week ago, incidentally, I was pointed to a package in Dag Wieers' repository, which he copied from my fedora.us package in early October, apparently saving him time. He has still not descended from his high horse to reply to my private mail. Though, on the same day he repaired the package silently already.
Michael, don't start another war. I fixed the package because you were right and I did not answer your mail because it was another highly explosive one.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
thanks, dag, for all your hard work. i sure appreciate what you do. i sure hope that something can end up being worked out at some point. but, please, don't let michael and his ilk bring you down. you and axel and the others are very much appreciated and valued.
heh. this: [Any errors in spelling, tact or fact are transmission errors] brings lots of smiles to my face. fine sense of humor, my friend.
john
On Mon, 29 Nov 2004 03:31:54 -0600, john bray wrote:
but, please, don't let michael and his ilk bring you down.
Yeah, pour some gasoline into the fire, without insight.
Good opportunity for me to take a time-out from fedora-list and unsubscribe. These topics only hurt productivity.
Michael
Michael Schwendt wrote:
On Sun, 28 Nov 2004 16:39:24 -0700, Scott wrote:
<snip>
If "3-4 people" think they can create and maintain more than 1000 packages alone, let them do it. Thank them for doing it, if those packages seem to work fine for you. Although I don't see that all those packages are up-to-date or moving faster than packages in fedora.us.
Actually, it looks like Matthias at FreshRPMs, who is only one person, has a more updated version of ALSA on his website for Fedora Core 1 than does Fedora Extras. And I don't even think he is maintaining Core 1 anymore. So wise up.
<snip>
Btw, just a week ago, incidentally, I was pointed to a package in Dag Wieers' repository, which he copied from my fedora.us package in early October, apparently saving him time. He has still not descended from his high horse to reply to my private mail. Though, on the same day he repaired the package silently already.
It's Free software, who cares? Get over it.
<snip>
They really need to take a hard look at this.
Not fedora.us. Why should the active contributors at fedora.us see existing 3rd party repositories as competition and try to provide the same packages?
Hello, we aren't suggesting competition here! What have we been saying guys? "COOPERATION! COORDINATION!"
---- Peace, William
On Sun, 2004-11-28 at 16:11 -0500, William M. Quarles wrote:
OK, someone pointed this out to me:
http://www.fedora.us/wiki/RepositoryMixingProblems
Join us or we'll start reproducing your software in your place anyways. Does this not scream arrogance, bureacracy, and monopoly to anybody else? Does this not seem very Microsoft-ish?
No, it's a direct, inevitable and necessary consequence of the way how repositories work.
Ralf
On 11/28/2004 01:11:25 PM, William M. Quarles wrote:
OK, someone pointed this out to me:
http://www.fedora.us/wiki/RepositoryMixingProblems
Join us or we'll start reproducing your software in your place anyways.
I don't think that is what they are saying. I think what they are saying is that their may be conflicts with their repository if you use someone elses as well, and that is a point worth considering.
That doesn't mean you can't use other repositories, it just means there might be some packaging conflicts you have to resolve (by telling one repo or the other to ignore certain packages).
I will say that I specifically do not like the fact that some of the popular repositories out there offer packages that REPLACE Fedora Core packages in the same repository as their add on packages - they really should separate those out to a different repository so that users like me who want to think long and hard before replacing a core package won't have to worry about that. Fedora Extras does not replace Core packages, it is safe to use. When it is available ;)
Michael A. Peters wrote:
On 11/28/2004 01:11:25 PM, William M. Quarles wrote:
I will say that I specifically do not like the fact that some of the popular repositories out there offer packages that REPLACE Fedora Core packages in the same repository as their add on packages - they really should separate those out to a different repository so that users like me who want to think long and hard before replacing a core package won't have to worry about that. Fedora Extras does not replace Core packages, it is safe to use. When it is available ;)
Well, Fedora is hypothetically cutting and bleeding edge, but quite frankly a lot of the packages that show up in it are out of date. The need for these maintainers to supply updated packages just points more strongly at the fact that Fedora is running behind on some packages, and updates are necessary for other software to be useful with it.
The Linux kernel itself has traditionally been missing a lot of well-deserved optimizations, and Red Hat has made it a tradition to modify the kernel for better hardware support and bug-fixes. As for kernel packages, some of the maintainers feel that they are doing the same. Planet CCRMA says exactly why they need to have a modified kernel.
http://ccrma.stanford.edu/planetccrma/software/installkernelandsound.html http://ccrma.stanford.edu/planetccrma/software/system.html
However, the nice thing about kernel packages is that they don't have to replace the official packages.
Peace, William
Am So, den 28.11.2004 schrieb William M. Quarles um 23:24:
Well, Fedora is hypothetically cutting and bleeding edge, but quite frankly a lot of the packages that show up in it are out of date. The need for these maintainers to supply updated packages just points more strongly at the fact that Fedora is running behind on some packages, and updates are necessary for other software to be useful with it.
Can you be specific and give quite some examples for the "lot of ... packages ... out of date"?
William
Alexander
On Sun, 2004-11-28 at 23:31 +0100, Alexander Dalloz wrote:
Am So, den 28.11.2004 schrieb William M. Quarles um 23:24:
Well, Fedora is hypothetically cutting and bleeding edge, but quite frankly a lot of the packages that show up in it are out of date. The need for these maintainers to supply updated packages just points more strongly at the fact that Fedora is running behind on some packages, and updates are necessary for other software to be useful with it.
Can you be specific and give quite some examples for the "lot of ... packages ... out of date"?
William
Alexander
Alexander,
I certainly cannot state that many packages are out of date, but as a result of a recent discussion in another community, I can point out that the current readline package (readline-4.3-13) is out of date, as readline-5.0 was released back in July.
That's one anyway...
Regards,
Marc Schwartz
Marc Schwartz wrote:
Alexander,
I certainly cannot state that many packages are out of date, but as a result of a recent discussion in another community, I can point out that the current readline package (readline-4.3-13) is out of date, as readline-5.0 was released back in July.
That's one anyway...
Regards,
Marc Schwartz
Mozilla Firefox and Thunderbird are others as well. They did manage to get an update to Firefox out shortly after the FC3 release. I'm still waiting on Thunderbird though.......
Actually, I'm no t waiting, I gave up and built my own TB 0.9 RPM...
Scott
Alexander Dalloz wrote:
Am So, den 28.11.2004 schrieb William M. Quarles um 23:24:
Well, Fedora is hypothetically cutting and bleeding edge, but quite frankly a lot of the packages that show up in it are out of date. The need for these maintainers to supply updated packages just points more strongly at the fact that Fedora is running behind on some packages, and updates are necessary for other software to be useful with it.
Can you be specific and give quite some examples for the "lot of ... packages ... out of date"?
Of the top of my head, here is one example. It looks like someone else gave another. Mozilla on Fedora Core and Red Hat Linux has been generally running pretty well behind the official Mozilla releases. Which is very odd considering that The Fedora Project has usually been right on top of updating the obviously less important Gaim.
I remember on Red Hat Linux 9 I came across an awful bug in Mozilla that prevented anything (automatic or manual) from moving more than one message at a time when it involved an IMAP server. It was probably the worst functionality (i.e. non-fatal) bug I have ever seen in any program, and it was very obvious. I found that the bug was fixed in an offical Mozilla release. I reported this on Red Hat Bugzilla, and they told me that they did not anticipate releasing any future versions of Mozilla for Red Hat Linux 9. They ended up doing it several months later anyways, but it wasn't just for my bug. These two paragraphs seem to tell me that there are some Mozilla/Red Hat politics going on of which I am not aware.
After Fedora Core 2 came out, I recompiled its Mozilla 1.6 for Fedora Core 1 (which even at that time was behind because Mozilla 1.7 was out, but as I recall Mozilla 1.7 had some minor issues in it). It works perfectly and can be found on my website at http://physstud.jmu.edu/quarlewm/. I modified the spec file so that it actually gets i686 optimizations (the original spec file did not have one instance of $RPM_OPT_FLAGS in it). I tried recompiling the Mozilla 1.7.3 Fedora Core 2 SRPM for Fedora Core 1, but compilation hasn't worked yet.
If you want more it will take me some time to put together a list.
---- Peace, William
On Monday 29 November 2004 06:24, William M. Quarles wrote:
Well, Fedora is hypothetically cutting and bleeding edge, but quite frankly a lot of the packages that show up in it are out of date. The need for these maintainers to supply updated packages just points more strongly at the fact that Fedora is running behind on some packages, and updates are necessary for other software to be useful with it.
My interpretation of the wiki is that If a package is old, and the existing maintainer is uninterested or unable to upgrade then you an do it yourself and offer the results to the archive.
If that doesn't suit you you could try recording a "RFE" bug report against the package.
The idea of the community is that if something doesn't suit you, you can work to improve it.
On Monday 29 November 2004 05:44, Michael A. Peters wrote:
That doesn't mean you can't use other repositories, it just means there might be some packaging conflicts you have to resolve (by telling one repo or the other to ignore certain packages).
For a time I used apt-get.org to find updated packages for Debian/Woody. I didn't actually haveproblems, but I didn't kno wht was going on either and I eventually simply upgraded toSarge (testing) which is probably not as hazardous as Rawhide, but then it's not exactly stable either.
The problem is this: Somein .hu created a current set of Moz packages for Woody and decided to share them. I found their site via apt-get.org and added the appropriate lines to my sources.list. I did likewise for KDE 3.x and various other packages.
The potential problem is this (this did not actually happen AFAIK): .hu decides to share KDE and XFfree too. My next apt-gget update && apt-get upgrade picks up unexpected packages from .hu.
Hmm. Not good for maintenance.
apt-get has a pinning capability to deal with this, but that's not widely known.
Besides I really don't know that those sites are reliable. I think i6 woild be quite easy to get myself listed for, say shorewall, and (maybe just oocasionally) ship a trojanned IRC bot that woild fone home to my temporary Yahoo account and tell me where it is.
My bot could then repair the trojanned IRC bot and leave me quietly sharing control of a machine to be used for spamming or a DoS attack on your favourite site.
I've not yet delved into yum, but I'd be a bit careful about what repos to add. Adding bulk sources for packages is altogether a different matter to downloading the occasional package fpm sf.net or freshrpms.net or wherever.
On Sun, 28 Nov 2004, Michael A. Peters wrote:
I will say that I specifically do not like the fact that some of the popular repositories out there offer packages that REPLACE Fedora Core packages in the same repository as their add on packages - they really should separate those out to a different repository so that users like me who want to think long and hard before replacing a core package won't have to worry about that. Fedora Extras does not replace Core packages, it is safe to use. When it is available ;)
Ok, this has come up several times and I should make a FAQ out of it. Why do people assume that the repository maintainer should be appointed of the burden of managing 2 or more repositories to just fullfil the way users want to use a repository ?
To me, this should be a feature of Yum and Apt. David Parsley (of TaoLinux fame) has a patch for Yum that exactly allows to protect the base system (core packages). You can say, this and this repository I consider the core repository and it will never allow to replace a package from these by one from another repository.
The implementation at this point has 1 problem case (when a non core package requires a core package), that will probably never get fixed since Seth (author of Yum) made it clear he was not interested in this feature and David sees no use in making it work for 100% if it will never get merged anyway.
Apt allows this by use of pinning packages/repositories (a feature that Yum does not have either) although the configuration if Apt's pinning functionality is a major disaster and should be part of a developer's hall of shame all by itself :)
Summary: I don't think a repository maintainer should suffer because applications lack functionality that users want. Especially if it can be automated fairly easily (ie. the path of the least amount of work).
BTW the core packages that are replaced (at least from the RPMforge project, FreshRPMS, Dries, Dag and PlanetCCRMA) are minor, only for leaf-packages (not libraries) and if there's a real need. My website has a Rationale attached to each of these packages.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On Mon, Nov 29, 2004 at 03:53:46AM +0100, Dag Wieers wrote:
To me, this should be a feature of Yum and Apt. David Parsley (of TaoLinux fame) has a patch for Yum that exactly allows to protect the base system (core packages). You can say, this and this repository I consider the core repository and it will never allow to replace a package from these by one from another repository.
Not only that, but there's a patch in Tao that also protects the vendor - in other words, DAG won't be allowed to replace a Tao package with it turned on. I requested that patch myself so that Dag couldn't replace a core package (rsynch was one such example). It works fine.
Like everything else, choice is good. You can use the Dag repository or other repositories. Sometimes you can mix and match but not always. If there's a package from a repository that you really want and Dag doesn't have it, you could test a rebuild on your system and ask Dag to include it.
On 11/28/2004 06:53:46 PM, Dag Wieers wrote:
Ok, this has come up several times and I should make a FAQ out of it. Why do people assume that the repository maintainer should be appointed of the burden of managing 2 or more repositories to just fullfil the way users want to use a repository ?
You shouldn't in an ideal world.
To me, this should be a feature of Yum and Apt.
I agree. I think rpm and/or repo software should alert a user when a package installed from one source is cued to be replace by another.
David Parsley (of TaoLinux fame) has a patch for Yum that exactly allows to protect the base system (core packages). You can say, this and this repository I consider the core repository and it will never allow to replace a package from these by one from another repository.
I like the sound of that.
The implementation at this point has 1 problem case (when a non core package requires a core package), that will probably never get fixed since Seth (author of Yum) made it clear he was not interested in this feature and David sees no use in making it work for 100% if it will never get merged anyway.
That's too bad - I like the sound of that, it's a safety feature for the user. Maybe if seth doesn't want it in yum, Fedora could add it themselves to their yum.
On Mon, Nov 29, 2004 at 05:03:19AM +0000, Michael A. Peters wrote:
I agree. I think rpm and/or repo software should alert a user when a package installed from one source is cued to be replace by another.
It's gotta be able to work non-interactively.
On 11/29/2004 06:56:32 AM, Matthew Miller wrote:
On Mon, Nov 29, 2004 at 05:03:19AM +0000, Michael A. Peters wrote:
I agree. I think rpm and/or repo software should alert a user when a package
installed from one source is cued to be replace by another.
It's gotta be able to work non-interactively.
simple. Have a priority list that yum (optionally) looks at.
[fedora-updates] [base] [freshrpms] [dag] [livna-stable] [JoesCoolPackages]
If an available package is in fedora-updates and in JoesCoolPackages - yum sees that fedora-updates is higher on list, so it takes priority regardless of the epoch/version/release in JoesCoolPackages.
If you ask for a package from dag that has a requirement fulfilled in both dag and freshrpms, it sees that freshrpms is higher in your list than dag so it grabs the dependency from freshrpms.
-=- Another thing - I hate beuracracy but this may be needed - a neutral naming authority. In cases where packages conflict simply because of different package name, if the naming can't be fixed between the repos themselves, let an independent community group decide.
Naming conflicts SHOULD be rare because usually an rpm should bear the name of the source (or binary in case of things like divx4linux) tarball. One exception is things like plugins. I package the libvisual plugin for xmms - tarball name is libvisual-xmms but xmms plugins are always xmms-package so I rename it to xmms-libvisual. I think that is pretty easy for repo maintainers to figure out, and is common practice.
But dag is 100% right that there should be better cooperation resolving those kinds of issues, one of the main benefits of open source imho is choice, and choice should include who packages your extras.
On Mon, Nov 29, 2004 at 06:44:10PM +0000, Michael A. Peters wrote:
Another thing - I hate beuracracy but this may be needed - a neutral naming authority. In cases where packages conflict simply because of different package name, if the naming can't be fixed between the repos themselves, let an independent community group decide.
Fedora Extras _should be_ that independent community group.
On Mon, 2004-11-29 at 15:11 -0500, Matthew Miller wrote:
On Mon, Nov 29, 2004 at 06:44:10PM +0000, Michael A. Peters wrote:
Another thing - I hate beuracracy but this may be needed - a neutral naming authority. In cases where packages conflict simply because of different package name, if the naming can't be fixed between the repos themselves, let an independent community group decide.
Fedora Extras _should be_ that independent community group.
1. Fedora Extras is run and conducted by RH.
2. It is RH, who until now has refused to cooperate with developers on selecting N-V-R conventions. Until now, each of the 3rd parties (which Fedora.US had been one of) has invented its own conventions.
3. N-V-R's are only one kind package conflicts being involved in incompatibilities which occur when mixing repositories. There are many more, much worser hidden package dependencies "occasional users" will rarely notice.
Ralf
Ralf Corsepius wrote:
On Mon, 2004-11-29 at 15:11 -0500, Matthew Miller wrote:
On Mon, Nov 29, 2004 at 06:44:10PM +0000, Michael A. Peters wrote:
Another thing - I hate beuracracy but this may be needed - a neutral naming authority. In cases where packages conflict simply because of different package name, if the naming can't be fixed between the repos themselves, let an independent community group decide.
Fedora Extras _should be_ that independent community group.
Fedora Extras is run and conducted by RH.
It is RH, who until now has refused to cooperate with developers on
selecting N-V-R conventions. Until now, each of the 3rd parties (which Fedora.US had been one of) has invented its own conventions.
Not really. They actually are consulting with each other to try to keep up compatibility. But most of the maintainers of the packages in question simply take their name and version number from the source, which tends to minimize the "N-V" problems. The R problems are another story altogether.
- N-V-R's are only one kind package conflicts being involved in
incompatibilities which occur when mixing repositories. There are many more, much worser hidden package dependencies "occasional users" will rarely notice.
If tree falls in the forest but nobody is there to hear it, does it make a sound? My counterquestion would be, "Does it really matter?" For the user whom it does matter then (s)he most likely will notice and will let the maintainer know about it, which chances are (s)he is already in communication with the other package's maintainer as they try to coordinate to correct the problem. It really isn't as big of an issue as it might have been in the past.
---- Peace, William
On Mon, 2004-11-29 at 23:59 -0500, William M. Quarles wrote:
Ralf Corsepius wrote:
On Mon, 2004-11-29 at 15:11 -0500, Matthew Miller wrote:
On Mon, Nov 29, 2004 at 06:44:10PM +0000, Michael A. Peters wrote:
Another thing - I hate beuracracy but this may be needed - a neutral naming authority. In cases where packages conflict simply because of different package name, if the naming can't be fixed between the repos themselves, let an independent community group decide.
Fedora Extras _should be_ that independent community group.
Fedora Extras is run and conducted by RH.
It is RH, who until now has refused to cooperate with developers on
selecting N-V-R conventions. Until now, each of the 3rd parties (which Fedora.US had been one of) has invented its own conventions.
Not really. They actually are consulting with each other to try to keep up compatibility. But most of the maintainers of the packages in question simply take their name and version number from the source, which tends to minimize the "N-V" problems.
No disagreement on this part. This part is more or less obvious.
The R problems are another story altogether.
This and the epoch:-issue is the troublesome part of the story. Wrt. this not even RH seems to have a convention shared between their developers.
- N-V-R's are only one kind package conflicts being involved in
incompatibilities which occur when mixing repositories. There are many more, much worser hidden package dependencies "occasional users" will rarely notice.
If tree falls in the forest but nobody is there to hear it, does it make a sound? My counterquestion would be, "Does it really matter?"
Yes, it does.
It won't matter in probably 90% of all cases, but the remaining 10% can become ugly.
Most visible problem: * Installation directories, e.g. - Where and how to install *.desktop files into? - Where and how to install plugins into?
* Optional features: - Repositories provide packages having been compiled with different features enabled. - Repositories provide packages with different compilation/linking options enabled (e.g. static/dynamic libs)
* Conflicting dependencies: - Packages might be compiled against different versions of other libs, resulting into incompatible behavior. ...
Now think about why installations of multi-media players (e.g. totem) is troublesome and why so many people have problems in getting them functional.
Ralf
On Mon, Nov 29, 2004 at 03:53:46AM +0100, Dag Wieers wrote:
On Sun, 28 Nov 2004, Michael A. Peters wrote:
I will say that I specifically do not like the fact that some of the popular repositories out there offer packages that REPLACE Fedora Core packages in the same repository as their add on packages - they really should separate those out to a different repository so that users like me who want to think long and hard before replacing a core package won't have to worry about that. Fedora Extras does not replace Core packages, it is safe to use. When it is available ;)
Ok, this has come up several times and I should make a FAQ out of it. Why do people assume that the repository maintainer should be appointed of the burden of managing 2 or more repositories to just fullfil the way users want to use a repository ?
Or let me rephrase the problem, why do some people insist that replacing packages is bad? The replacements are obviously done for some reason, and not for reducing stability and security.
You can have far more severe issues by poorly written daemons and external kernel modules that are technically packaged in separate packages.
And for a reality check, when was there an issue with a replaced package? In fact I was glad to see when an ssh exploit was disclosed some time ago (a year+?) that several repos (dag, freshrpms and others I forget) had a fast fix closing that hole on my system.
To answer the question myself, the reasons there is a propaganda against repos offering vendor replacements can be found in the intentions of the people loudly proclaiming it's so dangerous to do so. It is just an arbitrary distinction mark from the repo they favour ...
On Monday 29 November 2004 19:07, Axel Thimm wrote:
Or let me rephrase the problem, why do some people insist that replacing packages is bad?
I used to be a systems programmer, a member of a team responsible for maintain the system software on multisquillion dollar IBM mainframes.
One of the things I learned there is that every step from the standard way of doing things brings more headaches.
Whenever we customised IBM's software (and we did), we needed a plan to ensure a smooth transition to the next IBM release.
Whenever we installed software from another vendor (and we did), we needed a plan to ensure that the different sets of software worked together smoothly, and to be sure we could update smoothly to the next releases of each.
There is a reason RH highlights that you cannot upgrade a system with Ximian's Gnome packages in place: Ximian's packages are different (why else would anyone want them) and conflict with what RH provides. I expect no less.
If I want to package software for RHEL or Fedora Core I will target a specific environment, most probably a standard install with no third-party extras. What else _can_ I do? Unless I'm enhancing one of those extras of course. It's up to administrators (often the users) to ensure that they don't have conflicting packages, of they do, to have a plan to work around the difficulties that will arise.
I will, of course, expect you to read the documentation I provide, before installing and maybe before acquiring the sotware.
On Mon, 2004-11-29 at 20:26 +0800, John Summerfield wrote:
On Monday 29 November 2004 19:07, Axel Thimm wrote:
Or let me rephrase the problem, why do some people insist that replacing packages is bad?
I used to be a systems programmer, a member of a team responsible for maintain the system software on multisquillion dollar IBM mainframes.
One of the things I learned there is that every step from the standard way of doing things brings more headaches.
Whenever we customised IBM's software (and we did), we needed a plan to ensure a smooth transition to the next IBM release.
Whenever we installed software from another vendor (and we did), we needed a plan to ensure that the different sets of software worked together smoothly, and to be sure we could update smoothly to the next releases of each.
There is a reason RH highlights that you cannot upgrade a system with Ximian's Gnome packages in place: Ximian's packages are different (why else would anyone want them) and conflict with what RH provides. I expect no less.
Exactly, and if you are writing or packaging an application to run on the base os it behooves you to make certain your package does not impair the standard distribution, or at least document in detail the changes it makes.
If I want to package software for RHEL or Fedora Core I will target a specific environment, most probably a standard install with no third-party extras. What else _can_ I do? Unless I'm enhancing one of those extras of course. It's up to administrators (often the users) to ensure that they don't have conflicting packages, of they do, to have a plan to work around the difficulties that will arise.
And for packagers such as Ximian above, they have to expect and plan for problems in updates whenever the user moves to a newer release of the platform they are running on.
Currently, IBM for example, has customers that are stuck on a version of AIX that is not even supported by IBM at this time because of age, simply due to the application developer's delay/failure in providing package updates to support operation on the newer OS version.
I will, of course, expect you to read the documentation I provide, before installing and maybe before acquiring the sotware.
And this is one problem with third party packagers. Non-standard naming/packaging practices and the extent by which some modify the core OS make compatibility choices difficult. Total lack of documentation on the changes and compatibilities make it hard to know what is right, so using a site where everything is known to "just work" without breaking something else is a big factor.
With open source software anyone is free to make the modifications they choose, and on the other side, *users* are free to select the packages and repository they choose as well.
I myself choose standardization and less intrusive applications so I have gone with Dag and ATrpms repositories since they have indicated they want to cooperate and standardize the procedure. Fedora.US and Livna have lost my vote here (although I may use some of their packages as long as it doesn't break something else).
Recently I tried to do a yum update (when I had the fedora.us repository enabled) and it failed because of dependencies on several libraries that WERE installed. It seemed the packages selected from fedora.us were trying to remove some libraries that were required by installed packages. I removed fedora.us from my list of repositories and the update went flawlessly after that.
-- Cheers John
Jeff Vian wrote:
Recently I tried to do a yum update (when I had the fedora.us repository enabled) and it failed because of dependencies on several libraries that WERE installed. It seemed the packages selected from fedora.us were trying to remove some libraries that were required by installed packages. I removed fedora.us from my list of repositories and the update went flawlessly after that.
I love it!
Jeff Vian wrote:
<snip>
And this is one problem with third party packagers. Non-standard naming/packaging practices and the extent by which some modify the core OS make compatibility choices difficult. Total lack of documentation on the changes and compatibilities make it hard to know what is right, so using a site where everything is known to "just work" without breaking something else is a big factor.
<snip>
I'm confused about the "so using a site where everything is known to "just work" without breaking something else is a big factor" part. A little clarfication might be helpful.
FreshRPMs has complete descriptions and changelogs for every SRPM its website if you go there to download individual packages. However, it's much more efficient to just use Yum or APT, which doesn't deal you any documentation. Perhaps a more upfront "this is what installing my stuff using Yum/APT will do to your system" would be helpful.
---- Peace, William
On Mon, 2004-11-29 at 22:58 -0500, William M. Quarles wrote:
Jeff Vian wrote:
<snip> > And this is one problem with third party packagers. Non-standard > naming/packaging practices and the extent by which some modify the core > OS make compatibility choices difficult. Total lack of documentation on > the changes and compatibilities make it hard to know what is right, so > using a site where everything is known to "just work" without breaking > something else is a big factor. <snip>
I'm confused about the "so using a site where everything is known to "just work" without breaking something else is a big factor" part. A little clarfication might be helpful.
That comment was based on reputation gleaned from the mailing list, as well as personal experience (good with some repositories, not so good with others).
FreshRPMs has complete descriptions and changelogs for every SRPM its website if you go there to download individual packages. However, it's much more efficient to just use Yum or APT, which doesn't deal you any documentation. Perhaps a more upfront "this is what installing my stuff using Yum/APT will do to your system" would be helpful.
Peace, William
On Mon, 29 Nov 2004, Axel Thimm wrote:
Or let me rephrase the problem, why do some people insist that replacing packages is bad? The replacements are obviously done for some reason, and not for reducing stability and security.
It's not necessarily bad, but I can understand that people wish to avoid them. It's about offering choice the same way as you'd say to exclude some package from some repository for whatever reason is acceptable for yourself.
To answer the question myself, the reasons there is a propaganda against repos offering vendor replacements can be found in the intentions of the people loudly proclaiming it's so dangerous to do so. It is just an arbitrary distinction mark from the repo they favour ...
Though it shouldn't hold us back to offer that choice anyway, if it can be done by one of the tools.
PS In case you have a RHEL subscription, the need for such a feature is even higher.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On Mon, Nov 29, 2004 at 02:54:43PM +0100, Dag Wieers wrote:
On Mon, 29 Nov 2004, Axel Thimm wrote:
Or let me rephrase the problem, why do some people insist that replacing packages is bad? The replacements are obviously done for some reason, and not for reducing stability and security.
It's not necessarily bad, but I can understand that people wish to avoid them. It's about offering choice the same way as you'd say to exclude some package from some repository for whatever reason is acceptable for yourself.
To answer the question myself, the reasons there is a propaganda against repos offering vendor replacements can be found in the intentions of the people loudly proclaiming it's so dangerous to do so. It is just an arbitrary distinction mark from the repo they favour ...
Though it shouldn't hold us back to offer that choice anyway, if it can be done by one of the tools.
Agreed, I'm focussing on the propaganda part.
Having this support in tools is nice to have (apt already has this feature), but using this as an argument against repos is quite silly.
PS In case you have a RHEL subscription, the need for such a feature is even higher.
Yes, you will get your support voided if you replace packages. RHEL is a completely different game.
On 11/29/2004 03:07:17 AM, Axel Thimm wrote:
Or let me rephrase the problem, why do some people insist that replacing packages is bad? The replacements are obviously done for some reason, and not for reducing stability and security.
It's bad for several reasons -
1) Bugzilla. A user has a bug in a program, they report it to bugzilla, clueless to the fact that their Fedora binary was replaced by my package and that the bug may not be present in the Fedora binary.
2) Security Fedora does sometimes patch packages for security. Say Fedora puts a security patch in balsa-2.2.4 but the user is running my balsa-2.2.5 package - which also has the vulnerability, but I am not aware of it or the patch.
Fedora releases a new balsa 2.2.4 package fixing the security issue, but the user doesn't get the update because they have balsa 2.2.5
3) Newer isn't always better. Maybe libfoobar.so.3.3 provides something that a fooripper needs that libfoobar.so.3.2 doesn't provide, but at the same breaks some things that I did not test for when packaging the newer libfoobar.
On Mon, Nov 29, 2004 at 06:54:08PM +0000, Michael A. Peters wrote:
On 11/29/2004 03:07:17 AM, Axel Thimm wrote:
Or let me rephrase the problem, why do some people insist that replacing packages is bad? The replacements are obviously done for some reason, and not for reducing stability and security.
It's bad for several reasons -
- Bugzilla.
A user has a bug in a program, they report it to bugzilla, clueless to the fact that their Fedora binary was replaced by my package and that the bug may not be present in the Fedora binary.
rpm -qi is your friend, and I have not seen one bug at bugzilla.redhat.com that was accidentially for a 3rd party repo (not that I exclude that there will be any, but this hasn't ever been articulated to be a problem).
After all one of the first entries you have to make is the version-release of the package.
- Security
Fedora does sometimes patch packages for security. Say Fedora puts a security patch in balsa-2.2.4 but the user is running my balsa-2.2.5 package - which also has the vulnerability, but I am not aware of it or the patch.
That's not confined to packages replacing core packages. If your package has a security flaw, be it a replacement or not, you need to fix it, otherwise you leave open holes on your users' systems. In fact the situation is worse with non-replaced packages, as for replacements there is a good chance that the updated core packages will close your security hole (and a lot of replaced packages have a versioning scheme to automatically fallback to the security updated vendor package, e.g. see the ATrpms' kernels).
Fedora releases a new balsa 2.2.4 package fixing the security issue, but the user doesn't get the update because they have balsa 2.2.5
- Newer isn't always better.
That's hardly a focus for the patches/updates/replacements. "Newer is better" is rawhide's job. The largest part of the updates are due to other packages requiring it.
Maybe libfoobar.so.3.3 provides something that a fooripper needs that libfoobar.so.3.2 doesn't provide, but at the same breaks some things that I did not test for when packaging the newer libfoobar.
Michael A. Peters wrote:
On 11/29/2004 03:07:17 AM, Axel Thimm wrote:
Or let me rephrase the problem, why do some people insist that replacing packages is bad? The replacements are obviously done for some reason, and not for reducing stability and security.
It's bad for several reasons -
- Bugzilla.
A user has a bug in a program, they report it to bugzilla, clueless to the fact that their Fedora binary was replaced by my package and that the bug may not be present in the Fedora binary.
I might agree with you on that one, except that a user should really run an rpm -q package_name (possibly even rpm -qi) before reporting a bug. Red Hat's Bugzilla actually requests users to do this task for this reason (and has done so at least ever since I started seriously messing around with RHL back in the 7.1 days) (-qi is my idea though).
- Security
Fedora does sometimes patch packages for security. Say Fedora puts a security patch in balsa-2.2.4 but the user is running my balsa-2.2.5 package - which also has the vulnerability, but I am not aware of it or the patch.
Fedora releases a new balsa 2.2.4 package fixing the security issue, but the user doesn't get the update because they have balsa 2.2.5
Not every package has security vulnerabilities. This also goes against what Axel said earlier that the repositories were faster to respond with a patched OpenSSH than Red Hat was. These guys are on top of their game and should not be doubted.
In addition (other than the OpenSSH example), I haven't found a replacement package yet that had any potential security vulnerabilities (see next).
- Newer isn't always better.
Maybe libfoobar.so.3.3 provides something that a fooripper needs that libfoobar.so.3.2 doesn't provide, but at the same breaks some things that I did not test for when packaging the newer libfoobar.
As pointed out by Dag elsewhere on this thread (I'm proud that I could start such a huge one!), "BTW the core packages that are replaced (at least from the RPMforge project, FreshRPMS, Dries, Dag and PlanetCCRMA) are minor, only for leaf-packages (not libraries) and if there's a real need. My website has a Rationale attached to each of these packages." So your example is mute.
---- Peace, William
Dag Wieers wrote:
<snip>
Apt allows this by use of pinning packages/repositories (a feature that Yum does not have either) although the configuration if Apt's pinning functionality is a major disaster and should be part of a developer's hall of shame all by itself :)
I've used APT to upgrade packages, and I've read about this "pinning" feature before; what is this "pinning"?
Summary: I don't think a repository maintainer should suffer because applications lack functionality that users want. Especially if it can be automated fairly easily (ie. the path of the least amount of work).
BTW the core packages that are replaced (at least from the RPMforge project, FreshRPMS, Dries, Dag and PlanetCCRMA) are minor, only for leaf-packages (not libraries) and if there's a real need. My website has a Rationale attached to each of these packages.
I just got told about this Fedora Alternatives subproject; sounds like the same stuff only it probably won't work as good as FreshRPMS, et al. Seriously, the replacement packages that I have used never break compatibility with Fedora Core programs. They are usually adding something to that package's features rather than taking or breaking away.
---- Peace, William
On Mon, 2004-11-29 at 22:44 -0500, William M. Quarles wrote:
Dag Wieers wrote:
<snip> > Apt allows this by use of pinning packages/repositories (a feature that > Yum does not have either) although the configuration if Apt's pinning > functionality is a major disaster and should be part of a developer's hall > of shame all by itself :)
I've used APT to upgrade packages, and I've read about this "pinning" feature before; what is this "pinning"?
man 5 apt_preferences
In a nutshell: Apt's way to assign priorities to packages and repositories to certain packages preference over others. It could be applied to resolve package conflicts. Unfortunately it is not easy to use and partially broken with apt-rpm.
Ralf
On Sun, 28 Nov 2004 16:11:25 -0500, William M. Quarles wrote:
OK, someone pointed this out to me:
http://www.fedora.us/wiki/RepositoryMixingProblems
Join us or we'll start reproducing your software in your place anyways. Does this not scream arrogance, bureacracy, and monopoly to anybody else? Does this not seem very Microsoft-ish?
You try to read between the lines and end up with something which is not what the page tries to point out. It makes your thoughts and your choice of words appear unnecessarily aggressive.
Can you actually expect to have a single community to maintain every single piece of free software for Fedora Core (talk about a super bloat to the Fedora Project)?
That question is full of prejudice, it cannot be answered in a single sentence. There is only a "single community", the Fedora community, the community of Fedora Core users. How we, the community, manage to organize ourselves, is another question. Whether individual packagers wish to contribute their packages to a central repository or create an own repository on their website is up to them. The distribution explicitly includes tools, which aid 3rd party packagers. Some software only targets niche markets. Other software, e.g. binary only releases or non-redistributable software, could not be included in Fedora Core and not Fedora Extras either. And there will always be room for independent packagers, who choose a different road of packaging.
Basically, it some piece of free software is not popular enough and nobody (not even its developers) is willing to maintain packages for it, it won't be included.
Doesn't this seem to go against some of the good things about free software?
What? You think that software X, which is included in repository A, must not be included in repository B?
It seems that a set of extra libraries and applications that aren't "Core" but are still fundamental or very widely used should be the focus of Fedora Extras. Basically, take some software that is very redundantly distributed by other repositories to reduce overlap and increase compatibility, and not try to take over every package that every other repository makes.
Discuss...
I don't understand this last paragraph, I'm afraid. And I don't see anyone at fedora.us trying to taking "every package that every other repository makes".
Spend some time thinking about inter-repository coordination and scalability of inter-repository dependencies. People have thought about it before. The Wiki page you've found gives only a rough summary of the problems. Present a complete guide on how to solve inter-repository collaboration, also with respect to the different repository development models. That would be food for discussion. But don't be afraid of analyzing why there is not a single repository only. Discussing conspiracy theories is a waste of time.
On Mon, Nov 29, 2004 at 05:41:57AM +0100, Michael Schwendt wrote:
On Sun, 28 Nov 2004 16:11:25 -0500, William M. Quarles wrote:
OK, someone pointed this out to me:
http://www.fedora.us/wiki/RepositoryMixingProblems
Join us or we'll start reproducing your software in your place anyways. Does this not scream arrogance, bureacracy, and monopoly to anybody else? Does this not seem very Microsoft-ish?
You try to read between the lines and end up with something which is not what the page tries to point out. It makes your thoughts and your choice of words appear unnecessarily aggressive.
Let's get some original quotes, Michael does have a very poor memory, it seems.
http://www.fedora.us/wiki/RepositoryMixingProblems?version=1 | 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:
(Note: this specific versioned entry was deleted from the wiki after I quoted the above some time ago ...)
http://lists.freshrpms.net/pipermail/freshrpms-list/2003-November/006430.htm... | I would assert that the alliances of 3rd party repositories that | have tried to form in the recent past are not sustainable in the | long term, for the same controversial reasons that fedora.us | rejected cooperation with those entities earlier this year.
[....] I don't understand this last paragraph, I'm afraid. And I don't see anyone at fedora.us trying to taking "every package that every other repository makes".
http://lists.freshrpms.net/pipermail/freshrpms-list/2003-February/002997.htm... | These packages would be vital to actually attract users to the | project. | More users would attract more attention, and perhaps more | developers would join us. Please help me convert Matthias' | FreshRPMS to the Fedora naming scheme.
Spend some time thinking about inter-repository coordination and scalability of inter-repository dependencies. People have thought about it before.
... and made very valuable contributions to the naming scheme which were dropped simply because they favoured multiple repo setups (w/o blocking a single repo setup).
Present a complete guide on how to solve inter-repository collaboration,
You mean like the efforts in spring 2003 where every single submission to the docs wrt interoperability went to /dev/null? That's a good tactic, let the opponents Bang Their Harts Against Some Mad Bugger's Wall (TM).
OK, Axel, you really need to go on a comedy tour. Number three of laughter for me for the day.
I've got to ask, how do you come up with these quotes so quickly and readily? Where everybody forgets, you always seem to remember.
Peace, William
Axel Thimm wrote:
On Mon, Nov 29, 2004 at 05:41:57AM +0100, Michael Schwendt wrote:
On Sun, 28 Nov 2004 16:11:25 -0500, William M. Quarles wrote:
OK, someone pointed this out to me:
http://www.fedora.us/wiki/RepositoryMixingProblems
Join us or we'll start reproducing your software in your place anyways. Does this not scream arrogance, bureacracy, and monopoly to anybody else? Does this not seem very Microsoft-ish?
You try to read between the lines and end up with something which is not what the page tries to point out. It makes your thoughts and your choice of words appear unnecessarily aggressive.
Let's get some original quotes, Michael does have a very poor memory, it seems.
http://www.fedora.us/wiki/RepositoryMixingProblems?version=1 | 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:
(Note: this specific versioned entry was deleted from the wiki after I quoted the above some time ago ...)
http://lists.freshrpms.net/pipermail/freshrpms-list/2003-November/006430.htm... | I would assert that the alliances of 3rd party repositories that | have tried to form in the recent past are not sustainable in the | long term, for the same controversial reasons that fedora.us | rejected cooperation with those entities earlier this year.
[....] I don't understand this last paragraph, I'm afraid. And I don't see anyone at fedora.us trying to taking "every package that every other repository makes".
http://lists.freshrpms.net/pipermail/freshrpms-list/2003-February/002997.htm... | These packages would be vital to actually attract users to the | project. | More users would attract more attention, and perhaps more | developers would join us. Please help me convert Matthias' | FreshRPMS to the Fedora naming scheme.
Spend some time thinking about inter-repository coordination and scalability of inter-repository dependencies. People have thought about it before.
... and made very valuable contributions to the naming scheme which were dropped simply because they favoured multiple repo setups (w/o blocking a single repo setup).
Present a complete guide on how to solve inter-repository collaboration,
You mean like the efforts in spring 2003 where every single submission to the docs wrt interoperability went to /dev/null? That's a good tactic, let the opponents Bang Their Harts Against Some Mad Bugger's Wall (TM).
-
Alexander Dalloz -
Axel Thimm -
Chris Stark -
Dag Wieers -
Dries Verachtert -
Ed Hill -
Ed Wilts -
Erik Kjær Pedersen -
Jef Spaleta -
Jeff Vian -
john bray -
John Summerfield -
Marc Schwartz -
Matthew Miller -
Michael A. Peters -
Michael Schwendt -
Mike Ramirez -
Rahul Sundaram -
Ralf Corsepius -
Scott -
William M. Quarles