Your message dated Thu, 23 Apr 2009 08:41:54 -0700
with message-id <[email protected]>
and subject line Re: Bug#375331: aptitude: more fine-grained control over
strictness in conflict resolution
has caused the Debian Bug report #375331,
regarding aptitude: more fine-grained control over strictness in conflict
resolution
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
375331: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375331
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: aptitude
Version: 0.4.1-1.1
Severity: wishlist
Hi,
I'm using pkgsync, which uses aptitude as the underlying mechanism, with
mile-long command lines that look something like this:
aptitude dist-upgrade foo+ bar+ baz- 'quux&M'
(99% are + and &M lines, FWIW.)
Sometimes, however, this goes awry, as the conflict resolution mechanism
decides to, say, not pull in GNOME because this makes it has to
downgrade some other package to the version in testing etc..
Normally, I'd solve this by something along the lines of
aptitude -o Aptitude::cmdline::Request-Strictness=10000 install gnome
(I really do believe the strictness should be set that high by default,
BTW, but that's for another bug report :-) )
but when there's a couple thousand arguments at the command line, this
naturally won't help. So, having something that lets me prioritize the
individual choices on the command line would be great; something along
the lines of
aptitude dist-upgrade gnome+//10000 bar+ baz-//500 'quux&M'
to give a penalty of 10000 to whatever solution doesn't manage to get
GNOME in, 500 to whatever solution doesn't get baz out, etc.. I'm afraid
I don't know the aptitude code particularily well, but given that the
request strictness is in there already, I hope this isn't something
that's impossible to bolt in :-)
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16trofastxen
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Versions of packages aptitude depends on:
ii apt [libapt-pkg-libc6.3-6-3.1 0.6.44.2 Advanced front-end for dpkg
ii libc6 2.3.6-15 GNU C Library: Shared libraries
ii libgcc1 1:4.1.1-5 GCC support library
ii libncursesw5 5.5-2 Shared libraries for terminal hand
ii libsigc++-2.0-0c2a 2.0.16-3 type-safe Signal Framework for C++
ii libstdc++6 4.1.1-5 The GNU Standard C++ Library v3
Versions of packages aptitude recommends:
ii aptitude-doc-en [aptitude-doc 0.4.1-1.1 English manual for aptitude, a ter
-- debconf-show failed
--- End Message ---
--- Begin Message ---
Version: 0.5.1-1
I came across this bug while preparing the changelog for aptitude
0.5.2. aptitude has had a mechanism of resolver "hints" since 0.5.1
which I think addresses what this bug was asking for. In 0.5.2 it'll
get even better, since the tiering framework lets you set hints that are
*guaranteed* to be obeyed by the resolver (right now the types of hints
you can set are very limited, but I expect to change that in the
future).
So I think this can be closed in the experimental branch.
Daniel
--- End Message ---
