So, is there interest to have ATrpms for FC5 less overlapping with core packages?
If so, is there any redhat.com folk that would be willing to add versioned obsoletes/provides to core specfiles? That's neccessary to ensure upgradability.
On Sat, 2005-12-31 at 20:50 +0100, Axel Thimm wrote:
If so, is there any redhat.com folk that would be willing to add versioned obsoletes/provides to core specfiles? That's neccessary to ensure upgradability.
Can you show specific examples of where this is required? In bugzilla, perhaps?
Axel Thimm wrote:
If so, is there any redhat.com folk that would be willing to add versioned obsoletes/provides to core specfiles? That's neccessary to ensure upgradability.
They (redhat folk) have been receptive to Versioning previously non-versioned Obsoletes/Provides in the past when I've requested it on several occasions.
However, if you're asking in the context "will they add these simply to be compatible/upgradable with ATrpms", then I bet the proposition will be less well-received.
-- Rex
Rex Dieter wrote:
Axel Thimm wrote:
If so, is there any redhat.com folk that would be willing to add versioned obsoletes/provides to core specfiles? That's neccessary to ensure upgradability.
They (redhat folk) have been receptive to Versioning previously non-versioned Obsoletes/Provides in the past when I've requested it on several occasions.
However, if you're asking in the context "will they add these simply to be compatible/upgradable with ATrpms", then I bet the proposition will be less well-received.
-- Rex
Please don't make this into a political thing. Axel provides a great service to the Redhat/Fedora user community. Lets have a discussion about the technicalities, and just do it.
Can I assume we're looking for solutions that also help DAG, Dries, Livna ?
John
On Sat, 2005-12-31 at 20:50 +0100, Axel Thimm wrote:
So, is there interest to have ATrpms for FC5 less overlapping with core packages?
ATrpms is a great repository, but my perpetual pet peeve is that it replaces and messes with way too many packages in the distribution. If that's the overlapping that you refer to, I'd be glad to see it reduced.
I very much prefer the model of Extras and Livna, which don't replace anything, just add things.
Axel Thimm wrote:
So, is there interest to have ATrpms for FC5 less overlapping with core packages?
Less overlap is probably a good thing. It should at least free up some of your resources for non-overlapping packages.
However, I doubt that overlaps can be completely eliminated, or that it is even desirable to completely eliminate them, so I think it is more important to have a clear mechanism to allow the user to control the default choice, and to be able to override it if desired.
If so, is there any redhat.com folk that would be willing to add versioned obsoletes/provides to core specfiles? That's neccessary to ensure upgradability.
Hopefully, but what can we do to minimize their effort?
John
Once upon a time, John Ellson ellson@research.att.com said:
However, I doubt that overlaps can be completely eliminated, or that it is even desirable to completely eliminate them, so I think it is more important to have a clear mechanism to allow the user to control the default choice, and to be able to override it if desired.
The best thing would be for the third-party repos to be split into overlapping and non-overlapping. Anything that doesn't replace a Core or Extras package (or require such a package) could go in a non-overlapping repo and things that does could go in an "alternatives" repo.
That would leave the choice in the hands of the users; if they just want to add some compatible software to their Fedora system, they can just use a third-party base non-overlapping repo. If they want to replace Core and/or Extras packages with enhanced/updated/etc. packages from a third part repo, they use that third-party's alternatives repo.
That still requires some end-user "buy-in"; I might want just one alternative from a third-party without wanting others, but I don't see it being practical to make it any finer grained.
On 1/1/06, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, John Ellson ellson@research.att.com said:
However, I doubt that overlaps can be completely eliminated, or that it is even desirable to completely eliminate them, so I think it is more important to have a clear mechanism to allow the user to control the default choice, and to be able to override it if desired.
The best thing would be for the third-party repos to be split into overlapping and non-overlapping. Anything that doesn't replace a Core or Extras package (or require such a package) could go in a non-overlapping repo and things that does could go in an "alternatives" repo.
It could be doable. But, it would be inconsistent in some cases and also would be a major set back as things would have to be restructured. For example, the reason there are so many overlapping packages between RPMforge and Extras is that the goals have diverged. RPMforge maintains specs in a way that will make them compatible with a wide range of distros. Extras is more of a laser-beam, forward-looking approach. There are groups of people who fall under the banners of either side.
The fact of the matter is, is that the user *chose* to integrate the third party repo into their system. The act of doing this should come with responsibility. Protecting them will do nothing to help the situation.
-- -jeff
Hi
The fact of the matter is, is that the user *chose* to integrate the third party repo into their system. The act of doing this should come with responsibility. Protecting them will do nothing to help the situation.
When users choose to use third party repositories they are in many cases not aware that they are not just adding packages but also replacing existing ones in their system which might be a divergence they desire. The discussions initiated by one such user along with various posting in fedora forum, user lists and irc channel is enough proof that the problem exists. Also dag, one of the third party repository packagers has essentially required the exact same thing before.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151498
Claiming that the problem is theoretical is ignoring the issue and calling it politics or FUD is not going to change that.
regards Rahul
On Mon, 2006-01-02 at 05:24 +0530, Rahul Sundaram wrote:
When users choose to use third party repositories they are in many cases not aware that they are not just adding packages but also replacing existing ones in their system which might be a divergence they desire. The discussions initiated by one such user along with various posting in fedora forum, user lists and irc channel is enough proof that the problem exists. Also dag, one of the third party repository packagers has essentially required the exact same thing before.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151498
Claiming that the problem is theoretical is ignoring the issue and calling it politics or FUD is not going to change that.
Have we thought about maybe an 'installonly' type plugin for 3rd party repos? Only allow the installation of packages from that repo, exclude it from generic 'update' calls, or only allow packages that have been installed from said repo to be updated from said repo (and specific deps)? This would allow users to install specific package sets and avoid generic update issues. I tried to install some mono stuff from nrpms, left nrpms configured and did a yum update and was prompted to update a very large amount of my core over to nrpms versions of packages. Not cool.
On Mon, 2006-01-02 at 05:24 +0530, Rahul Sundaram wrote:
When users choose to use third party repositories they are in many cases not aware that they are not just adding packages but also replacing existing ones in their system which might be a divergence they desire. The discussions initiated by one such user along with various posting in fedora forum, user lists and irc channel is enough proof that the problem exists.
This is currently the single most important problem with package repositories.
It's the repositories hell, the vengeful progeny of the near-deceased RPM dependencies hell.
On 1/2/06, Florin Andrei florin@andrei.myip.org wrote:
On Mon, 2006-01-02 at 05:24 +0530, Rahul Sundaram wrote:
When users choose to use third party repositories they are in many cases not aware that they are not just adding packages but also replacing existing ones in their system which might be a divergence they desire. The discussions initiated by one such user along with various posting in fedora forum, user lists and irc channel is enough proof that the problem exists.
(Offtopic: is anyone else's mail not picking up Rahul's list postings? I've seen several responses to Rahul's email, however I haven't received any from Rahul since 12/27 from fedora-devel. Odd...)
This is currently the single most important problem with package repositories.
See Warren's posting: Core/Extras has no obligation to help the situation.
It's the repositories hell, the vengeful progeny of the near-deceased RPM dependencies hell.
Not really. If it's "hell", don't use them. Pretty simple.
If you'd like to help improve 3rd party repos, file bugs and/or patches to make the situation better. Also, participate in the mailing lists that the 3rd party repos have setup.
And the situation is not synonymous with rpm dep hell, because with apt/yum/smart you don't have to install a random rpm and then download thirty other random rpms to satisfy deps. It's automatic. And if it's broken, see last paragraph.
The issue is whether Core/Extras should protect base. Most of the 3rd party repo people have chimed in with a unanimous thumb down. Some have doubts about whether Core<->Extras migrations would work well. And only a few have given this a thumbs up with vague explanations as to why it should be default. Security being only a thin coverup for a reason.
I say the idea, while it might be novel, is DOA. Especially w.r.t. to "Core/Extras has no obligations to 3rd parties". So if there is no obligation, then there is no need for protectbase.
-- -jeff
On Mon, 2006-01-02 at 14:10 +0800, Jeff Pitman wrote:
(Offtopic: is anyone else's mail not picking up Rahul's list postings? I've seen several responses to Rahul's email, however I haven't received any from Rahul since 12/27 from fedora-devel. Odd...)
I seem to be receiving them okay. Have you checked the relevant logs? Perhaps the messages may have been mistakenly marked as Junk or similar? :-/
On Mon, 2006-01-02 at 14:10 +0800, Jeff Pitman wrote:
On 1/2/06, Florin Andrei florin@andrei.myip.org wrote:
It's the repositories hell, the vengeful progeny of the near-deceased RPM dependencies hell.
Not really. If it's "hell", don't use them. Pretty simple.
Right, so repository XYZ carries the package ABC, which I need, but since XYZ fosters the repo hell, I shall simply walk away whistling.
Makes no sense to me, really. The concept of package repositories is a very powerful one, but this current situation is crippling.
Fedora per se, plus Extras, is nice, solid and coherent. Fedora plus the repositories ecosystem is currently an entity with a serious multiple personality disorder.
And the situation is not synonymous with rpm dep hell, because with apt/yum/smart you don't have to install a random rpm and then download thirty other random rpms to satisfy deps.
I didn't say it's synonymous. But it can be equally frustrating. Or more. Such as, enable repo XYZ, do a "yum update", get a broken system ("broken" as in "does not work anymore with any other repo, and XYZ must be perpetually used from now on otherwise funky things happen"). Do not pass Go, do not collect $200.
The issue is whether Core/Extras should protect base. Most of the 3rd party repo people have chimed in with a unanimous thumb down.
3rd party repos have no business fiddling with the core packages, since that is the root cause of the repo hell. It boggles the mind that this is not a self-evident truth.
All I see is a rant and a censoring of my statement about how you can contribute to the 3rd party repository. Remember: "Core/Extras has no obligation" to help 3rd party repos or enforce a world-wide policy. That's up to you. And, that's why /etc/yum.repos.d isn't populated with 3rd party repos by default.
On 1/2/06, Florin Andrei florin@andrei.myip.org wrote:
On Mon, 2006-01-02 at 14:10 +0800, Jeff Pitman wrote:
On 1/2/06, Florin Andrei florin@andrei.myip.org wrote:
It's the repositories hell, the vengeful progeny of the near-deceased RPM dependencies hell.
Not really. If it's "hell", don't use them. Pretty simple.
Right, so repository XYZ carries the package ABC, which I need, but since XYZ fosters the repo hell, I shall simply walk away whistling.
Makes no sense to me, really. The concept of package repositories is a very powerful one, but this current situation is crippling.
Fedora per se, plus Extras, is nice, solid and coherent. Fedora plus the repositories ecosystem is currently an entity with a serious multiple personality disorder.
And the situation is not synonymous with rpm dep hell, because with apt/yum/smart you don't have to install a random rpm and then download thirty other random rpms to satisfy deps.
I didn't say it's synonymous. But it can be equally frustrating. Or more. Such as, enable repo XYZ, do a "yum update", get a broken system ("broken" as in "does not work anymore with any other repo, and XYZ must be perpetually used from now on otherwise funky things happen"). Do not pass Go, do not collect $200.
The issue is whether Core/Extras should protect base. Most of the 3rd party repo people have chimed in with a unanimous thumb down.
3rd party repos have no business fiddling with the core packages, since that is the root cause of the repo hell. It boggles the mind that this is not a self-evident truth.
-- Florin Andrei
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- -jeff
On Sun, 2006-01-01 at 22:44 -0800, Florin Andrei wrote:
On Mon, 2006-01-02 at 14:10 +0800, Jeff Pitman wrote:
On 1/2/06, Florin Andrei florin@andrei.myip.org wrote:
It's the repositories hell, the vengeful progeny of the near-deceased RPM dependencies hell.
Not really. If it's "hell", don't use them. Pretty simple.
Right, so repository XYZ carries the package ABC, which I need, but since XYZ fosters the repo hell, I shall simply walk away whistling.
Makes no sense to me, really. The concept of package repositories is a very powerful one, but this current situation is crippling.
The situation is crippling imho only because a newer EVR will always be chosen by yum, which I think *could* be improved - wether it is Fedora's responsibility to or not.
*snip*
3rd party repos have no business fiddling with the core packages, since that is the root cause of the repo hell. It boggles the mind that this is not a self-evident truth.
There are times when it is a must. In order to use Package C you may need core Package A linked against something that core package A isn't linked against.
In the past I would rebuild the gd library with gif support on my own system so that I could build php with gif support. That's no longer needed.
In the past I would rebuild the libtiff library with lzw support. That also is no longer needed.
I still rebuild sox with mp3 support because I have not (yet) found a suitable swiss army knife type of easily scriptable tool for recording an input stream and encoding straight to mp3. Might be able to do it with gstreamer pipes, but sox just does it.
Those are *my* personal needs that cause(d) me to replace core packages. I'm sure others have similar situations, and these third party repo's fill those needs - sometimes as dependencies.
That is a service to the Fedora community that sometimes Fedora itself can't fill due to patent/licensing issues etc.
If instead of just looking at EVR yum could look at DPEVR where D is dependency, P is repository priority, things might be better.
D would be by default 0 - and incremented for each dependency in the transaction it fulfills.
For example - if atrpms had sox with mp3 support that had : provides: sox-mp3 - then yum could figure out that when sox-mp3 is required, to bump the D for the atrpms sox package causing it to replace the core sox package BUT ONLY if the sox-mp3 is required by something.
The core sox package would provide sox and thus have a D of one, but the atrpms sox would provide both sox and sox-mp3 and thus have a D value of 2 so it would have priority. That may be a dumb way to do it, not well thought out, but anyway ...
The P could be a priority setting that is inherited from a repository global priority but can be over-ridden on a per package basis. Thus I could have rpm.livna.org have a higher global priority than atrpms - but give the gstreamer plugins in atrpms higher individual priority than livna, for example. P would only be used if the D value were the same.
If the P and D value is the same, then EVR is used. Right now only EVR is used.
The problem is that rpm does not store in its database repository information so figuring out P for installed packages is difficult, though that potentially could be figured out from GPG sig - under the big (false) assumption that each repository only uses one GPG key (rawhide has a couple, and some are sometimes not signed at all)
On 1/2/06, Michael A. Peters mpeters@mac.com wrote:
If instead of just looking at EVR yum could look at DPEVR where D is dependency, P is repository priority, things might be better.
You know that depsolve is mostly delegated to rpmlib, right?
[cut ... Explanation for a possible solution ... cut]
I think it will come down to this ... use yum for Core/Extras and where default behavior of a 3rd party repo is acceptable to you. Otherwise, use smart for any other weird, magic, bit-twiddling behavior needs.
If a plugin can provide the solution you layed out, then by all means, provide it. I highly doubt the proposed solution will go into yum proper.
-- -jeff
On Mon, 2006-01-02 at 16:33 +0800, Jeff Pitman wrote:
On 1/2/06, Michael A. Peters mpeters@mac.com wrote:
If instead of just looking at EVR yum could look at DPEVR where D is dependency, P is repository priority, things might be better.
You know that depsolve is mostly delegated to rpmlib, right?
Yup - and that's a problem.
[cut ... Explanation for a possible solution ... cut]
I think it will come down to this ... use yum for Core/Extras and where default behavior of a 3rd party repo is acceptable to you. Otherwise, use smart for any other weird, magic, bit-twiddling behavior needs.
But if smart can do it - yum could potentially be taught to do it as well.
If a plugin can provide the solution you layed out, then by all means, provide it. I highly doubt the proposed solution will go into yum proper.
Not anytime soon. I'm guessing though it would require yum to keep a database of its own to know what came from where - which would be way to fragile because anything not installed by yum would not be in there.
So unless yum has another way to figure out what packages come from where, it probably is never going to be optimal and therefore never implemented.
On Sun, Jan 01, 2006 at 10:44:36PM -0800, Florin Andrei wrote:
Right, so repository XYZ carries the package ABC, which I need, but since XYZ fosters the repo hell, I shall simply walk away whistling.
The correct thing to do would be to:
1) Complain to the repo maintainer that replacing Core (and Extras?) packages is a big no-no. 2) Find out why said repo maintainer feels the need to replace said packages 3) Submit a bug in Bugzilla to solve repo maintainer's need 4) Wait for bug to be resolved. Wait for repo maintainer to rebuild packages that don't conflict with Core/Extras anymore.
3rd party repos have no business fiddling with the core packages, since that is the root cause of the repo hell. It boggles the mind that this is not a self-evident truth.
The problem isn't telling them this, it's finding out why it's happening and how to prevent it. Fight the cause, not the symptom.
Emmanuel
On Mon, 2006-01-02 at 12:10 +0100, Emmanuel Seyman wrote:
On Sun, Jan 01, 2006 at 10:44:36PM -0800, Florin Andrei wrote:
Right, so repository XYZ carries the package ABC, which I need, but since XYZ fosters the repo hell, I shall simply walk away whistling.
The correct thing to do would be to:
- Complain to the repo maintainer that replacing Core (and Extras?) packages is a big no-no.
- Find out why said repo maintainer feels the need to replace said packages
- Submit a bug in Bugzilla to solve repo maintainer's need
- Wait for bug to be resolved. Wait for repo maintainer to rebuild packages that don't conflict with Core/Extras anymore.
4a) Wait for bug to be CLOSED/WONTFIX because maintainer's needs would e.g. mean possibly violating patents.
Unless everything has plug-ins or some other witty scheme to handle that comes up, we will likely see people rebuilding core packages with stuff enabled that we don't.
Nils
On Mar 3 janvier 2006 10:00, Nils Philippsen wrote:
On Mon, 2006-01-02 at 12:10 +0100, Emmanuel Seyman wrote:
4a) Wait for bug to be CLOSED/WONTFIX because maintainer's needs would e.g. mean possibly violating patents.
Unless everything has plug-ins or some other witty scheme to handle that comes up, we will likely see people rebuilding core packages with stuff enabled that we don't.
Now that gstreamer got working mp3/mpeg2/dvd pluggins in livna, a lot of the video-related forks could be solved by just using totem or another gstreamer-based app as video player.
Seems this is the only video stack right now that got clean pluggin separation, enabling free/non-free repo separation without overlaps.
Regards,
Jeff Pitman wrote:
On 1/2/06, Florin Andrei florin@andrei.myip.org wrote:
On Mon, 2006-01-02 at 05:24 +0530, Rahul Sundaram wrote:
When users choose to use third party repositories they are in many cases not aware that they are not just adding packages but also replacing existing ones in their system which might be a divergence they desire. The discussions initiated by one such user along with various posting in fedora forum, user lists and irc channel is enough proof that the problem exists.
(Offtopic: is anyone else's mail not picking up Rahul's list postings? I've seen several responses to Rahul's email, however I haven't received any from Rahul since 12/27 from fedora-devel. Odd...)
Maybe you put me in the killfile for making too much noise?. Thats entirely possible. You might not receive this anyway
regards Rahul
On 1/2/06, Rahul Sundaram sundaram@redhat.com wrote:
Maybe you put me in the killfile for making too much noise?. Thats entirely possible. You might not receive this anyway
Heh, gmail is marking you and several others as Spam. I don't silence anyone, by choice. :P
-- -jeff
On Mon, 2006-01-02 at 15:03 +0800, Jeff Pitman wrote:
On 1/2/06, Rahul Sundaram sundaram@redhat.com wrote:
Maybe you put me in the killfile for making too much noise?. Thats entirely possible. You might not receive this anyway
Heh, gmail is marking you and several others as Spam. I don't silence anyone, by choice. :P
WORKSFORME
Don't know if this will help or hinder tracking the problem, but I seem to be receiving all list mail just fine. I was actually just checking my spam box on Gmail yesterday and the day before, and saw no anomalies. I'm seeing all of Rahul's mail in particular, FWIW. Is this worth tracking data points somehow? If so, how?
Jeff Pitman wrote:
On 1/2/06, Florin Andrei florin@andrei.myip.org wrote:
On Mon, 2006-01-02 at 05:24 +0530, Rahul Sundaram wrote:
When users choose to use third party repositories they are in many cases not aware that they are not just adding packages but also replacing existing ones in their system which might be a divergence they desire. The discussions initiated by one such user along with various posting in fedora forum, user lists and irc channel is enough proof that the problem exists.
(Offtopic: is anyone else's mail not picking up Rahul's list postings? I've seen several responses to Rahul's email, however I haven't received any from Rahul since 12/27 from fedora-devel. Odd...)
This is currently the single most important problem with package repositories.
See Warren's posting: Core/Extras has no obligation to help the situation.
Furthermore, I personally consider 3rd party repositories to be forks of the distribution. In most cases this is no problem if they do not overlap and do not replace Core/Extras packages.
A "fork" is not necessarily a bad thing. Only users should be aware that they use such repositories at their own option, and if they have any problems they need to report it to their fork project/repository to deal with it. It is not Fedora's responsibility to workaround problems caused by forks or 3rd party software.
Warren Togami wtogami@redhat.com
On Monday 02 January 2006 16:53, Warren Togami wrote:
Jeff Pitman wrote:
On 1/2/06, Florin Andrei florin@andrei.myip.org wrote:
On Mon, 2006-01-02 at 05:24 +0530, Rahul Sundaram wrote:
When users choose to use third party repositories they are in many cases not aware that they are not just adding packages but also replacing existing ones in their system which might be a divergence they desire. The discussions initiated by one such user along with various posting in fedora forum, user lists and irc channel is enough proof that the problem exists.
(Offtopic: is anyone else's mail not picking up Rahul's list postings? I've seen several responses to Rahul's email, however I haven't received any from Rahul since 12/27 from fedora-devel. Odd...)
This is currently the single most important problem with package repositories.
See Warren's posting: Core/Extras has no obligation to help the situation.
Furthermore, I personally consider 3rd party repositories to be forks of the distribution. In most cases this is no problem if they do not overlap and do not replace Core/Extras packages.
A "fork" is not necessarily a bad thing. Only users should be aware that they use such repositories at their own option, and if they have any problems they need to report it to their fork project/repository to deal with it. It is not Fedora's responsibility to workaround problems caused by forks or 3rd party software.
While I agree that it isn't necessarily Fedora's responsibility to play nice with 3rd-party repositories, I think it ought to be a goal to make using 3rd-party repositories as painless as possible. I think there are quite a few people who might not use Fedora, if not for the 3rd-party repositories.
If there's a fix or functionality addition to a core package needed for another package maintained by a 3rd-party, why not push them into the core versions? Then people who want software out of the 3rd-party repo but don't want core packages replaced get to have their cake and eat it too, and 3rd-party repositories don't get bashed as much. Everybody wins, no?
Of course, someone within Red Hat would probably have to step up as 3rd-party repository liaison to coordinate the effort... But I think its something worth doing, for the sake of the Fedora community at large.
Jarod Wilson wrote:
On Monday 02 January 2006 16:53, Warren Togami wrote:
Furthermore, I personally consider 3rd party repositories to be forks of the distribution. In most cases this is no problem if they do not overlap and do not replace Core/Extras packages.
A "fork" is not necessarily a bad thing. Only users should be aware that they use such repositories at their own option, and if they have any problems they need to report it to their fork project/repository to deal with it. It is not Fedora's responsibility to workaround problems caused by forks or 3rd party software.
While I agree that it isn't necessarily Fedora's responsibility to play nice with 3rd-party repositories, I think it ought to be a goal to make using 3rd-party repositories as painless as possible. I think there are quite a few people who might not use Fedora, if not for the 3rd-party repositories.
If there's a fix or functionality addition to a core package needed for another package maintained by a 3rd-party, why not push them into the core versions? Then people who want software out of the 3rd-party repo but don't want core packages replaced get to have their cake and eat it too, and 3rd-party repositories don't get bashed as much. Everybody wins, no?
Of course, someone within Red Hat would probably have to step up as 3rd-party repository liaison to coordinate the effort... But I think its something worth doing, for the sake of the Fedora community at large.
It is an anti-goal of Fedora to promote the proliferation of arbitrary mixes of 3rd party repositories as the standard way of using Fedora. A central goal of Fedora is collaborative development in a centralized repository. For this reason it is untenable to expect or suggest Red Hat to explicitly coordinate with 3rd party repositories. Your post is also problematic in completely ignoring potential legal implications of an official relationship between Fedora and 3rd party repositories.
Users have an option of using 3rd party software, but the responsible party for dealing with problems shifts in such cases.
If you have concerns about individual packages, please file bugs in Red Hat Bugzilla. Changes can be made to individual Core/Extras packages are usually general bug fixes and enhancements. It is wrong to expect Fedora to make special concessions only to work around problems introduced by 3rd parties. If it is the right thing to do in general cases, then it is proper to make changes to Core/Extras.
Warren Togami wtogami@redhat.com
On Monday 02 January 2006 18:12, Warren Togami wrote:
Jarod Wilson wrote:
While I agree that it isn't necessarily Fedora's responsibility to play nice with 3rd-party repositories, I think it ought to be a goal to make using 3rd-party repositories as painless as possible. I think there are quite a few people who might not use Fedora, if not for the 3rd-party repositories.
If there's a fix or functionality addition to a core package needed for another package maintained by a 3rd-party, why not push them into the core versions? Then people who want software out of the 3rd-party repo but don't want core packages replaced get to have their cake and eat it too, and 3rd-party repositories don't get bashed as much. Everybody wins, no?
Of course, someone within Red Hat would probably have to step up as 3rd-party repository liaison to coordinate the effort... But I think its something worth doing, for the sake of the Fedora community at large.
It is an anti-goal of Fedora to promote the proliferation of arbitrary mixes of 3rd party repositories as the standard way of using Fedora. A central goal of Fedora is collaborative development in a centralized repository.
I'm not saying Fedora should promote arbitrary mixes of 3rd-party repositories, just that there aren't really any good reasons not to cooperate with them, at least on some level. If repository X needs an updated libfoo to build application bar that tons of users want, why not update Core's libfoo? I suppose bugzilla is the place to log such requests right now, but many don't get addressed in a very timely fashion, leading to 3rd-party replacement packages and/or simply no longer bothering to log such request.
For this reason it is untenable to expect or suggest Red Hat to explicitly coordinate with 3rd party repositories.
Perhaps my use of "coordinate" wasn't the best. Strike "coordinate the effort" and replace with "maintain an open and active, bi-directional line of communication". There are several large 3rd-party repositories with a wealth of experience, so why not leverage them more? Fedora itself is definitely in the driver's seat, but why ignore directions from 3rd-party repositories, simply because they're 3rd-party?
Your post is also problematic in completely ignoring potential legal implications of an official relationship between Fedora and 3rd party repositories.
Okay, so don't make it an official relationship. (Can anyone say "livna"?). Of course, IANAL, but I don't see any legal problem with fixing or updating core libs/packages that are already in the distro, so long as it isn't adding mp3 support or the like.
Users have an option of using 3rd party software, but the responsible party for dealing with problems shifts in such cases.
If you have concerns about individual packages, please file bugs in Red Hat Bugzilla. Changes can be made to individual Core/Extras packages are usually general bug fixes and enhancements. It is wrong to expect Fedora to make special concessions only to work around problems introduced by 3rd parties. If it is the right thing to do in general cases, then it is proper to make changes to Core/Extras.
I'm not talking so much about problems introduced by 3rd-parties as I am about problems/deficiencies uncovered by 3rd-parties, i.e., fixing packages in Core in a timely fashion to eliminate the need of 3rd-party packagers to replace Core components.
On 1/3/06, Jarod Wilson jarod@wilsonet.com wrote:
On Monday 02 January 2006 18:12, Warren Togami wrote:
If you have concerns about individual packages, please file bugs in Red Hat Bugzilla. Changes can be made to individual Core/Extras packages are usually general bug fixes and enhancements. It is wrong to expect Fedora to make special concessions only to work around problems introduced by 3rd parties. If it is the right thing to do in general cases, then it is proper to make changes to Core/Extras.
I'm not talking so much about problems introduced by 3rd-parties as I am about problems/deficiencies uncovered by 3rd-parties, i.e., fixing packages in Core in a timely fashion to eliminate the need of 3rd-party packagers to replace Core components.
Also, it's good to have allies on the inside. See jpackage FAQ about "I tried to install foo on Fedora Core 2, but got lots of error messages and/or things don't work": http://www.jpackage.org/faq.php
Note the line:
"""This issue should be fixed in Fedora Core 3, thanks to Red Hat's involvement in JPackage."""
Google cache from one of the messages since the archive is broke: http://66.102.7.104/search?q=cache:I2Me1f05Eb0J:lists.zarb.org/pipermail/jpa...
Sound familiar? And, in about 6 months "Core/Extras vs 3rd Party" might show up on this list again...
-- -jeff
On Monday 02 January 2006 21:33, Jeff Pitman wrote:
On 1/3/06, Jarod Wilson jarod@wilsonet.com wrote:
On Monday 02 January 2006 18:12, Warren Togami wrote:
If you have concerns about individual packages, please file bugs in Red Hat Bugzilla. Changes can be made to individual Core/Extras packages are usually general bug fixes and enhancements. It is wrong to expect Fedora to make special concessions only to work around problems introduced by 3rd parties. If it is the right thing to do in general cases, then it is proper to make changes to Core/Extras.
I'm not talking so much about problems introduced by 3rd-parties as I am about problems/deficiencies uncovered by 3rd-parties, i.e., fixing packages in Core in a timely fashion to eliminate the need of 3rd-party packagers to replace Core components.
Also, it's good to have allies on the inside.
Very true. Most 3rd-party repos don't, apparently.
See jpackage FAQ about "I tried to install foo on Fedora Core 2, but got lots of error messages and/or things don't work": http://www.jpackage.org/faq.php
Note the line:
"""This issue should be fixed in Fedora Core 3, thanks to Red Hat's involvement in JPackage."""
So the anti-3rd-party repository stance isn't unilaterally applied against all 3rd-party repos, I take it?
Google cache from one of the messages since the archive is broke: http://66.102.7.104/search?q=cache:I2Me1f05Eb0J:lists.zarb.org/pipermail/jp ackage-discuss/2004-October/011253.html+jpackage-discuss++011253&hl=en&clien t=firefox-a
Sound familiar? And, in about 6 months "Core/Extras vs 3rd Party" might show up on this list again...
Yeah, most likely. But hey, if JPackage can get Red Hat's help, I don't see why other repositories can't...
On 1/3/06, Jarod Wilson jarod@wilsonet.com wrote:
On Monday 02 January 2006 21:33, Jeff Pitman wrote:
On 1/3/06, Jarod Wilson jarod@wilsonet.com wrote: Note the line:
"""This issue should be fixed in Fedora Core 3, thanks to Red Hat's involvement in JPackage."""
So the anti-3rd-party repository stance isn't unilaterally applied against all 3rd-party repos, I take it?
Right, generally, if you package for livna or jpackage, you're sitting pretty good. There's a lot of history behind this along with different packagers being in the right place at the right time. Basically, a specific repo has a social status and requires high merit points to get things moving in a direction that they need. It's a bit like us as individuals ... based on meritocracy and getting an inside scoop.
Besides social engineering, there is no other formal mechanism to push forward smooth operation between Core/Extras and a third party. If users are not privy to the fact that Core packages have to be updated sometimes, then they can either fork or not use.
It's a pretty simplistic view of things, but, it's the truth.
-- -jeff
Jarod Wilson wrote:
On Monday 02 January 2006 21:33, Jeff Pitman wrote:
On 1/3/06, Jarod Wilson jarod@wilsonet.com wrote:
On Monday 02 January 2006 18:12, Warren Togami wrote:
If you have concerns about individual packages, please file bugs in Red Hat Bugzilla. Changes can be made to individual Core/Extras packages are usually general bug fixes and enhancements. It is wrong to expect Fedora to make special concessions only to work around problems introduced by 3rd parties. If it is the right thing to do in general cases, then it is proper to make changes to Core/Extras.
I'm not talking so much about problems introduced by 3rd-parties as I am about problems/deficiencies uncovered by 3rd-parties, i.e., fixing packages in Core in a timely fashion to eliminate the need of 3rd-party packagers to replace Core components.
Also, it's good to have allies on the inside.
Very true. Most 3rd-party repos don't, apparently.
See jpackage FAQ about "I tried to install foo on Fedora Core 2, but got lots of error messages and/or things don't work": http://www.jpackage.org/faq.php
Note the line:
"""This issue should be fixed in Fedora Core 3, thanks to Red Hat's involvement in JPackage."""
So the anti-3rd-party repository stance isn't unilaterally applied against all 3rd-party repos, I take it?
There is no anti 3 party repository stance in the sense that there is nothing in the formal Fedora repositories working actively against them. If there are bugs in any of the packages within core they should fixed regardless of the 3rd party repositories which may have helped uncovered the problem. In other words they are just routine bugs addressed in bugzilla. No big board of (anti) cooperation required.
regards Rahul
On Wed, 2006-01-04 at 02:10 +0530, Rahul Sundaram wrote:
There is no anti 3 party repository stance in the sense that there is nothing in the formal Fedora repositories working actively against them. If there are bugs in any of the packages within core they should fixed regardless of the 3rd party repositories which may have helped uncovered the problem. In other words they are just routine bugs addressed in bugzilla. No big board of (anti) cooperation required.
There have been cases where Extras has used a different naming scheme than the third parties - I'm not sure how many though.
The extras review process is open though, and I don't know that it was ever done despite requests from the third parties against it. Nor do I think Extras should be obligated to follow third party naming schemes, not if doing so would violate the explicit extras naming scheme.
On Mon, 2006-01-02 at 20:18 -0800, Jarod Wilson wrote:
On Monday 02 January 2006 18:12, Warren Togami wrote:
I'm not saying Fedora should promote arbitrary mixes of 3rd-party repositories, just that there aren't really any good reasons not to cooperate with them, at least on some level. If repository X needs an updated libfoo to build application bar that tons of users want, why not update Core's libfoo?
One needs to be extremely cautious about updating a library in a live distro. I know it happens sometimes in Extras - but that is wrong too imho (unless they provide a compat package for the old version as well).
On 1/3/06, Michael A. Peters mpeters@mac.com wrote:
On Mon, 2006-01-02 at 20:18 -0800, Jarod Wilson wrote:
On Monday 02 January 2006 18:12, Warren Togami wrote:
I'm not saying Fedora should promote arbitrary mixes of 3rd-party repositories, just that there aren't really any good reasons not to cooperate with them, at least on some level. If repository X needs an updated libfoo to build application bar that tons of users want, why not update Core's libfoo?
One needs to be extremely cautious about updating a library in a live distro. I know it happens sometimes in Extras - but that is wrong too imho (unless they provide a compat package for the old version as well).
I doubt I am going to end the thread, but I hope to.
There are two sets of users: 1) users that do not want Core updated, and 2) users that *do* want Core updated.
Continuing to debate about why turns into a "emacs vs vi" debate. Seriously. Fedora should be agnostic as to either of these groups in any obvious, active endeavor. Of course, micro-steps need to be made on a per-package basis as reported via Bugzilla--when the maintainer finds it as an acceptable change. Otherwise, we work around them.
And a final comment to the those users in #1: do not use repos that cater to #2.
That's it.
-- -jeff
On Tue, 2006-01-03 at 14:22 +0800, Jeff Pitman wrote:
I doubt I am going to end the thread, but I hope to.
There are two sets of users: 1) users that do not want Core updated, and 2) users that *do* want Core updated.
Continuing to debate about why turns into a "emacs vs vi" debate.
which is a completely silly debate because everyone knows emacs is better. ;)
On 1/3/06, Michael A. Peters mpeters@mac.com wrote:
On Tue, 2006-01-03 at 14:22 +0800, Jeff Pitman wrote:
I doubt I am going to end the thread, but I hope to.
There are two sets of users: 1) users that do not want Core updated, and 2) users that *do* want Core updated.
Continuing to debate about why turns into a "emacs vs vi" debate.
which is a completely silly debate because everyone knows emacs is better. ;)
Ok fine, what about, "Would we have won WWII if the otherside had nuclear weapons?" debate.
-- -jeff
On 1/3/06, Jarod Wilson jarod@wilsonet.com wrote:
If there's a fix or functionality addition to a core package needed for another package maintained by a 3rd-party, why not push them into the core versions? Then people who want software out of the 3rd-party repo but don't want core packages replaced get to have their cake and eat it too, and 3rd-party repositories don't get bashed as much. Everybody wins, no?
I think what Warren is saying is that this channel already exists: in the form of Bugzilla. It would be at the discretion of each package maintainer to fold any improvements or patches into Core. So, there really doesn't need to be any explicit effort to bridge the two.
For example, I have submitted issues that were fixed in Core based on work that I was doing on my repo. This is due to the fact that my repo replaces Python well before Core does and so I can see some potential problems a priori Core integration.
But, that's not to say it doesn't get frustrating. I mean: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130352
That bug is a good example. It's a PITA. And, it will never get fixed. The implicit obsoletes kills a lot of attempts to stay away from Core packages. I tried to not touch the python package, but, I threw up my arms after trying for along time. So, you win some and you lose some.
Setting up a meta project to bridge 3rd party to Core will just be unnecessary because the same politics and technical issues will still exist.
-- -jeff
Jeff Pitman wrote:
But, that's not to say it doesn't get frustrating. I mean: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130352
That bug is a good example. It's a PITA. And, it will never get fixed. The implicit obsoletes kills a lot of attempts to stay away from Core packages. I tried to not touch the python package, but, I threw up my arms after trying for along time. So, you win some and you lose some.
rpm is the wrong component for this bug because it is behaving as designed. Why have you not asked the general python maintainers at Red Hat like misa, katzj or pjones instead? Maybe you have... but I see no comments from them in this ticket.
Communication problem?
Warren Togami wtogami@redhat.com
On 1/3/06, Warren Togami wtogami@redhat.com wrote:
rpm is the wrong component for this bug because it is behaving as designed. Why have you not asked the general python maintainers at Red Hat like misa, katzj or pjones instead? Maybe you have... but I see no comments from them in this ticket.
I resolved this by replacing the core package so I have python15, python22, python23, python24; instead of having "python" as the core package. Otherwise, an upgrade of python will implicitly Obsoletes the other packages because they Provide a virtual python. I actually ran through the scenarios, at length, with several individuals inside and outside of Redhat about 1.5+ years ago. This seemed to be the best resolution at the time since the aforementioned bug is "As Designed".
I'm mainly using this as an example about the occasional hiccups when dealing with Core and 3rd party repos rather than rattling old bones.
-- -jeff
Jeff Pitman wrote:
It could be doable. But, it would be inconsistent in some cases and also would be a major set back as things would have to be restructured. For example, the reason there are so many overlapping packages between RPMforge and Extras is that the goals have diverged. RPMforge maintains specs in a way that will make them compatible with a wide range of distros. Extras is more of a laser-beam, forward-looking approach. There are groups of people who fall under the banners of either side.
The fact of the matter is, is that the user *chose* to integrate the third party repo into their system. The act of doing this should come with responsibility. Protecting them will do nothing to help the situation.
Core and Extras are under no obligation to change anything to cater to any 3rd party, although the individual package maintainers have the option of doing so if it is reasonable. Regular changes in Core and Extras are possible if they are general bug fixes.
Warren Togami wtogami@redhat.com
Am Samstag, den 31.12.2005, 17:37 -0600 schrieb Chris Adams:
Once upon a time, John Ellson ellson@research.att.com said:
However, I doubt that overlaps can be completely eliminated, or that it is even desirable to completely eliminate them, so I think it is more important to have a clear mechanism to allow the user to control the default choice, and to be able to override it if desired.
The best thing would be for the third-party repos to be split into overlapping and non-overlapping.
And then merge the non-overlapping stuff in one 3rd party community repo where the repo-maintainers work together instead of against each other.
Okay, RPMforge might have other goals (see the mail from Jeff Pitman in this thread) so this probably won't fit (but I still wish RPMforge all the best with their approach).
But if livna, atrpms and freshrpms all mostly use the "don't replace packages from Core or Extras" approach it might be a good time do forget about old flamewars ^w discussions an try to work together from now on.
Disclaimer for those who don't know: I maintain several packages in Livna.
/me wonders if he should abort writing this message.
/me clicks "Send-Button" and hides
On Sat, 2005-12-31 at 17:37 -0600, Chris Adams wrote:
Once upon a time, John Ellson ellson@research.att.com said:
However, I doubt that overlaps can be completely eliminated, or that it is even desirable to completely eliminate them, so I think it is more important to have a clear mechanism to allow the user to control the default choice, and to be able to override it if desired.
The best thing would be for the third-party repos to be split into overlapping and non-overlapping.
The problem is there are a fair number of packages that are not overlapping but depend upon overlapping. So it really is difficult if you have a sizeable repository like Axel does.
AFAIK he's also supporting a large number of Fedora releases, and he's not charging anybody any money for it either. I think there could be a better solution that would allow him to spend more time on packages and less on repo monkey work.
On Sun, 2006-01-01 at 15:05 -0800, Michael A. Peters wrote:
The problem is there are a fair number of packages that are not overlapping but depend upon overlapping. So it really is difficult if you have a sizeable repository like Axel does.
My feeling is that 95% of all those "not overlapping but dependent" cases can be avoided with a healthy dose of common sense. Such as, less aggressive tracking of new releases, etc.
On 1/2/06, Florin Andrei florin@andrei.myip.org wrote:
On Sun, 2006-01-01 at 15:05 -0800, Michael A. Peters wrote:
The problem is there are a fair number of packages that are not overlapping but depend upon overlapping. So it really is difficult if you have a sizeable repository like Axel does.
My feeling is that 95% of all those "not overlapping but dependent" cases can be avoided with a healthy dose of common sense. Such as, less aggressive tracking of new releases, etc.
If you want less aggressive tracking, don't use 3rd party and/or use distro that matches this policy (eg. use CentOS instead).
-- -jeff
On Mon, 2006-01-02 at 14:51 +0800, Jeff Pitman wrote:
On 1/2/06, Florin Andrei florin@andrei.myip.org wrote:
On Sun, 2006-01-01 at 15:05 -0800, Michael A. Peters wrote:
The problem is there are a fair number of packages that are not overlapping but depend upon overlapping. So it really is difficult if you have a sizeable repository like Axel does.
My feeling is that 95% of all those "not overlapping but dependent" cases can be avoided with a healthy dose of common sense. Such as, less aggressive tracking of new releases, etc.
If you want less aggressive tracking, don't use 3rd party and/or use distro that matches this policy (eg. use CentOS instead).
I feel a communications breakdown here.
I was speaking about less aggressive version tracking in 3rd party repos with Fedora.
And "don't use 3rd party" is so bogus I'm not even going to debunk it.
On 1/2/06, Florin Andrei florin@andrei.myip.org wrote:
And "don't use 3rd party" is so bogus I'm not even going to debunk it.
It basically comes down to this, if a 3rd party is not doing something you like:
1. Communicate what's wrong on the 3rd party's mailing list. (Not on fedora's.) 2. Offer specs, patches, mechanisms, or scripts via 3rd party's mailing list and/or bugtracker.
If that fails to alter the course of the 3rd party repo into a direction you like, then you have the following choices:
1. Don't use the 3rd party repo. 2. Fork it and create your own. 3. Import packages into a repo that caters to your policies. 4. Rant about it randomly.
Anyway, this is all way off topic.
The conclusion of this thread is:
If there is a 3rd party repo having difficulty integrating with Core/Extras because of a Versioned Obsoletes problem, then hang a bugzilla for that specific package. Otherwise, Core/Extras has no obligation to take on a massive undertaking that would cater to 3rd party repositories.
That's it. -- -jeff
On Sat, 2005-12-31 at 20:50 +0100, Axel Thimm wrote:
So, is there interest to have ATrpms for FC5 less overlapping with core packages?
If so, is there any redhat.com folk that would be willing to add versioned obsoletes/provides to core specfiles? That's neccessary to ensure upgradability.
This might not be directly on topic to what was asked.
Is there a list for repository maintainers? I'm not asking because I think this is on wrong list, but I do think a list to collaboration between repository maintainers, and there is need to replace core packages in some circumstances.
IE - if I wrote a program that interfaces with an AM/FM radio tuner card to make mp3's that can be transfered to an iPod. I would probably just use sox to record the stream and output to mp3 - so my software would require an mp3 enabled sox.
With proper collaboration - packagers could requires sox-mp3 and the third parties could add Provides: sox-mp3 to their sox spec file.
That would allow dep resolvers to know that core sox isn't good enough.
I think the fundamental problem here is that EVR is being used to do some of that now, make the third party packages look newer to yum/apt so that dependencies are met - but the side affect that has is that sometimes replacement core packages that AREN'T needed for what the user is doing are pulled into a yum upgrade.
A "prefer base" plugin could (perhaps) be written such that core sox will not replaced by a non core package unless it sox is removed from core OR a third party sox provides something needed by another package that core sox does not provide (in this case sox-mp3)
I think that would avoid the need for a ton of sub repos to avoid un-necessary core package replacement as it currently is.
Even without a yum plugin that does things properly, though - using virtual provides and requires when necessary would at least inform users who have protectbase or whatever turned on that they can't do so and use some third party packages because dependencies would not be met - not based on EVR but based on what the core package doesn't provide that the third party requires.
These would need to be agreed upon by the repository maintainers, and a list for that would be beneficial if it doesn't exist.
On Sunday 01 January 2006 14:33, Michael A. Peters wrote:
Is there a list for repository maintainers?
http://lists.atrpms.net/mailman/listinfo/repo-coord
On 1/2/06, Michael A. Peters mpeters@mac.com wrote:
On Sat, 2005-12-31 at 20:50 +0100, Axel Thimm wrote:
So, is there interest to have ATrpms for FC5 less overlapping with core packages?
If so, is there any redhat.com folk that would be willing to add versioned obsoletes/provides to core specfiles? That's neccessary to ensure upgradability.
This might not be directly on topic to what was asked.
Is there a list for repository maintainers?
Axel runs one called "repo-coord" on atrpms.net. This has been around for quite awhile.
-- -jeff
Once upon a time Saturday 31 December 2005 1:50 pm, Axel Thimm wrote:
So, is there interest to have ATrpms for FC5 less overlapping with core packages?
If so, is there any redhat.com folk that would be willing to add versioned obsoletes/provides to core specfiles? That's neccessary to ensure upgradability.
I think that the best option would be to write a series of scripts the you can run before upgrade that will remove all of the third party packages and create a script for post install that will reinstall the packages removed. if you are not going to replace core packages anymore then that should work nicely.
The recomendation should be the same for an upgrade as those made for ximian packages.
The only issues i see with this is 1. you have replaced core packages that break dependancies, in which case a downgrade would be needed. 2. if 3rd party rpms that replace core funcionality are not removed the system upgrade could fail if new core package version-release is less that third party package.
All that can be done if bugs filed if packages decide to add obsoletes/provides then thats there choice
devel@lists.stg.fedoraproject.org
-
Axel Thimm -
Chris Adams -
David Woodhouse -
Dennis Gilmore -
Emmanuel Seyman -
Florin Andrei -
Jarod Wilson -
Jeff Pitman -
Jesse Keating -
John Ellson -
Michael A. Peters -
Nicolas Mailhot -
Nils Philippsen -
Paul W. Frields -
Peter Gordon -
Rahul Sundaram -
Rex Dieter -
Thorsten Leemhuis -
Warren Togami