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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
