[issue35] Option for making downgrades less attractive
Alexander Bergolth at Labix Tracker
tracker at labix.org
Thu Oct 27 11:32:28 PDT 2005
New submission from Alexander Bergolth <leo at strike.wu-wien.ac.at>:
Back in March there was a discussion about making downgrades less
attractive for smart (and the "min-downgrade-prio-diff" stuff) on the
mailinglist.
Since this would still be a very handy feature for me, I'll add it to
the tracker. I've also added some parts of the old email conversation
for reference.
Cheers,
--leo
-------------------- snipp! --------------------
On 03/26/05 16:28, Alexander Bergolth wrote:
> Have you ever thought of implementing a rule to make downgrades less
> attractive, like the first rule in apt's priority logic:
>
> Taken from man 5 apt_preferences:
>
> ---------- snipp! ----------
> ? Never downgrade unless the priority of an available version exceeds
> 1000. ("Downgrading" is installing a less recent version of a package in
> place of a more recent version. Note that none of APT's default
> priorities exceeds 1000; such high priorities can only be set in the
> preferences file. Note also that downgrading a package can be risky.)
> ---------- snipp! ----------
How about adding an option (e.g. min-downgrade-prio-diff) that allows
to specify the minimum difference between the less recent version and
the installed version that is required to downgrade the package? If
the default value is set to 0 it wouldn't change the status quo, if it
is set to a positive value, it can be used to emulate apt's behavior.
The implementation (together with yesterdays debugging-output changes)
could look like the attached patch...
(Not well-tested, I did just a quick test-run...)
--- transaction.py.orig 2005-03-26 13:33:33.508340680 +0100
+++ transaction.py 2005-03-26 19:15:20.270838920 +0100
@@ -980,14 +980,27 @@
continue
if isinst(upgpkg):
raise StopIteration
+ if pkg.name != upgpkg.name:
+ iface.debug(
+ "Adding upgrade %s: triggered by pkg "\
+ "%s: %s upgraded by %s"\
+ % (upgpkg, pkg, prv, upg))
_upgpkgs[upgpkg] = True
for upg in pkg.upgrades:
for prv in upg.providedby:
for prvpkg in prv.packages:
- if prvpkg.getPriority() <= pkgpriority:
+ if prvpkg.getPriority() - pkgpriority <= \
+ sysconf.get("min-downgrade-prio-diff", 0):
continue
if isinst(prvpkg):
raise StopIteration
+ msg = "Adding downgrade %s (higher prio): "\
+ "triggered by pkg %s which upgrades %s"\
+ % (prvpkg, pkg, upg)
+ if pkg.name != prvpkg.name:
+ iface.info(msg)
+ else:
+ iface.debug(msg)
_upgpkgs[prvpkg] = True
except StopIteration:
pass
-------------------- snipp! --------------------
On 03/28/05 21:18, Gustavo Niemeyer wrote:
>>> Being unable to detect when a downgrade was implicitly necessary is
>>> a deficience of APT in my POV. Check the case study #1 in the README
>>> file to see a real world example of Smart handling a necessary
>>> downgrade.
>>
>> How are different priority settions handled in such a case?
>> Suppose a package like glibc-gconvdata in avaliable on multiple channels
>> with different priorities. Are only the channels with the highest
>> priorities considered when it has to resolve such a situation?
>
>
> No. Unlike APT, Smart considers other cases as well. Priority will
> only tell the package precedence.
I'm glad to hear that. :)
>> The fact that a package will get the highest priority of all the channels
>> that provide it forced me to lower the priority of my rpm-db.
>> As soon as you use low priority channels, packages from that channels
>> would never be upgraded otherwise.
>
>
> Not correct. You may raise priorities of individual packages on that
> channel, if you want these packages to concur with your usual repository
> for upgrades based on version.
But I do not want packages from different channels concur based on version.
I'd like to use channel-priorities to define a ranking of channels. A
package should be installed from the channel with the highest
priority, versions should be checked only between packages of the same
channel (or related channels that have been assigned the same priority
like fedora-core and fedora-updates). However, if a new version of the
package becomes available on that channel, it should be considered for
upgrade.
If I use the setup you suggested and the rpm-db has a priority > any
channel C, an installed package will always be preferred over a
package on that channel C. That means that I'd have to raise the
priority of _every_ package that I install from channel C, otherwise
it will never be upgraded if a higher version becomes available on
that channel. That would result in a large list of (package-) priority
definitions.
> Again, higher priorities mean more interesting packages, no matter what
> the version says. If you want two different packages to have their
> version checked to see which one is more interesting, assign them equal
> priorities.
I think you misunderstood my intentions.
>> Suppose you have the following situation:
>>
>> RPM-DB: prio 0
>> Main-distro (preferred) channel A: prio 0
>> Additional channel B: prio -1
>>
>> If you install a package that is provided by channel B, it's priority
>> is "upgraded" to 0. Because priority counts higher than version, an
>> new version of that package from channel B will never be considered
>> for upgrade.
>
>
> Right. That's how it was supposed to work. If you want to track a
> single package from channel B, you should raise its priority on that
> specific channel. That's exactly why priorities may be assigned to
> individual packages on specific channels.
I'd like to track _many_ packages from channel B but only if those
packages are not available from channel A. And I don't want to define
an exception for every package from channel B.
> That's the help text for the priority command:
> """
> This command allows changing the priority of given packages.
> Packages with higher priorities are considered a better option
> even when package versions state otherwise. Using priorities
> one may avoid unwanted upgrades, force downgrades, select
> packages in given channels as preferential, and other kinds
> of interesting setups. When a package has no explicit priority,
> the channel priority is used. The channel priority may be
> changed using the 'channel' command, and defaults to 0 when
> not set.
> """
Yes, I'm aware of that, I'm already using package priorities for some
exceptions but I don't want to use them for every package that isn't
provided by the core distribution.
>> I believe that's the reason why apt's default priority for channels is
>> 500 while default priority of the installed packages RPM-DBs is 100.
>
>
> APT handles priorities differently.
>> If I lower the priority of the rpm-db to -2, any version from channel A
>> will be preferred but if that package isn't avaliable on channel A, a new
>> version on channel B will still be considered. That's exactly what I want.
>
>
> If you set your rpm database to a lower priority than your usual
> repository, you'll get downgrades and reinstallations for everything
> above its priority.
I'm aware of that. But the fact that the priority of a package-version
(if it has no explict package priority) is the highest priority of the
channels that provide it, helps me.
> That's how Slackware channels work, for instance.
> They don't have a strong representation of versions, and anything in
> the repository should be considered as an upgrade.
What I'd like to obtain is:
*) Any version in a channel with a higher channel-priority than the installed
package comes from, should be considered as an upgrade.
*) A higher version from the channel that the installed package comes from
should also be an upgrade.
That's exactly what my setup (using a lower rpm-db priority) does.
> With RPM, one usually won't want that.
See my argumentation above.
>> The patch I submitted in my self-reply would help in configurations with
>> different channel- (and rpm-db-) priorities without changing the default
>> behaviour.
> The patch you submitted is changing the way priorities work to something
> different than what it was designed for. Everything you asked so far
> is available in Smart as is. You're just using a bogus configuration.
Of course, using my channel-priority configuration, it would be
possible to override the channel order by defining package-priorities
for some packages that should not apply to that scheme.
But in general, I'd like to keep my priority defined by
channel-priorities I'm only treating a few exceptions that way. The
next time a higher version becomes available, the channel-rules should
apply again. If I add a package-rule for that package, it has to be
removed manually on the next package version. Furthermore I'd have to
add rules on every package that depends on that package-version in
order to prevent smart from downgrading.
E.g.: I'd like to manually install a higher version of the package
pango from a low priority channel to fix a temporary issue caused by a
bad package dependencies. I'd also need to upgrade pango-devel and all
packages that depend on that version of pango. In order to prevent
downgrading the package to the (higher-priority) default channel, I'd
have to set up package priorities for all of that packages.
Using my patch, smart would keep the installed package if I had set
the min-downgrade-prio-diff to a value higher than the channel
priority difference. Once my default channel provides the package with
the same or a higher version, smart will suggest that as an upgrade
and my temporary fix will be reverted.
I agree that my patch is extending the way priorities work but it
could help to prevent unwanted downgrades for those people who want it
to work that way. It shouldn't do any harm to smart's default
behaviour. (It would only copy one convenient characteristic from
apt. ;))
>> I believe that as soon as someone uses low-priority channels, it could
>> help to avoid unwanted downgrades of manually installed packages...
>
>
> I never had unwanted downgrades of manually installed packages, even
> though I've used low priority channels.
But maybe that's because you had the priority of your rpm-db set to 0,
which in turn makes it necessary to define exceptions in form of
package priorities for any packages on low-priority
channels. Otherwise they won't be upgraded automatically because the
rpm-db has a higher channel-priority. Cheers, --leo
-------------------- snipp! --------------------
[...]
>> I think you misunderstood my intentions.
Probably..
>> I'd like to track _many_ packages from channel B but only if those
>> packages are not available from channel A. And I don't want to define an
>> exception for every package from channel B.
[...]
>> Yes, I'm aware of that, I'm already using package priorities for some
>> exceptions but I don't want to use them for every package that isn't
>> provided by the core distribution.
Ok.. I think I finally understand what you want.
[...]
>> What I'd like to obtain is:
>> *) Any version in a channel with a higher channel-priority than the
>> installed package comes from, should be considered as an upgrade.
>> *) A higher version from the channel that the installed package comes
>> from should also be an upgrade.
Understood. I'll work on that for the next version. Thanks a lot
for taking the time to show me your intentions and explain why
they are interesting.
----------
messages: 82
nosy: bergolth
priority: feature
project: smart
status: unread
title: Option for making downgrades less attractive
_______________________________________
Labix issue tracker <tracker at labix.org>
<http://tracker.labix.org/issue35>
_______________________________________
More information about the Smart
mailing list