ATrpms and FC5/RHEL5

[Michael A. Peters]

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 at 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)