Understanding Prioritization

[Eli Wapniarski]

On Dec 19, 2005 11:49 AM, Gustavo Niemeyer <gustavo at niemeyer.net> wrote:

> Hello Eli,
> 
> > Is there anyway of getting a relatively indepth understanding of how
> > to set
> > prioritization. I'm using fc4 and have been managing my packages
> > with
> > apt-get. However, one of a number of the repositories that I rely on
> > has
> > discontinued support for apt-get. Prioritization in apt-get is
> > brilliant and
> > works. I need it to work as well in smart.
> 
> A package priority is currently considered in two distinct moments:
> 
> 1) When an upgrade operation is being prepared. If a package has a
>    higher priority, it is immediately considered as being an
>    upgrade/downgrade candidate over any other package connected to
>    that one by an "upgrades" relation (by either having the same name,
>    or having an "obsoletes" relation, in the case of RPM packages).
> 
> 2) When there are multiple alternatives for satisfying a dependency,
>    a package having a higher priority has more chances of being
>    selected to satisfy the dependency. That's not an isolated
>    decision though. For instance, if installing a package with a
>    higher priority would mean including dozens of other dependencies,
>    the priority *difference* between the higher priority package and
>    the other packages should be big enough to justify the change.
> 
> Point (1) behaves in a quite similar way to APT's pinning feature. On
> the other hand, point (2) doesn't.  In case you try it, your feedback
> on the current beahvior will be welcome.
> 
> > Any additional insight relative to the FAQ would be very very much
> > appreciated.

The behaviour I'm expecting, is one of exclusion. In apt, if I set a
priority of a repository to 999 then that repository has exclusive
priority over all other repositories that I'm using. 998 has the next
priority in that any package from the repo given the priority of 999
will not be superceeded by the 998 repository, but it will supercede
anything given a lower priority, even if it means downgrading. The thing
is, that repos build packages that occaisionally depend on packages that
they themselves have built to enable certain features. Features that
another repo may or may not include. A good example of this is the
relationship between kde-redhat's repo and Fedora's repo. The next repo
that I want to have priority of Fedora's is Freshrpms; especially over
Fedora extras for the same reasons.

So essentially, the behavior that I've come to expect and love with
priorities specified would be

1) kde-redhat (999) - Exclusively takes precedence over everything else.
Don't let anything else replace any file coming from the kde-redhat
                                          repo.
2) Freshrpms (998) - Takes precedence over everything other than
kde-redhat
3) everything below that is left at default.

I hope that this was presented clearly.

Eli