ATrpms and FC5/RHEL5

[Michael A. Peters]

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.