[Aptitude-devel] Bug#406976: aptitude: source-strictness is not strict enough

[Manuel A. Fernandez Montecelo]

2016-03-18 11:36 Steinar H. Gunderson:
>On Fri, Mar 18, 2016 at 11:33:41AM +0000, Manuel A. Fernandez Montecelo wrote:
>> Have you had some recent-ish experience with this, and remember if it
>> behaves in the same way?
>
>I don't think it's nearly as bad as it was, but it's still not _good_.
>Last instance I can recall was trying to install fglrx-driver on unstable
>(which requires downgrading X to the version in testing); it would frequently
>give me 2-3 completely bogus results before giving me one that would actually
>install the fglrx-driver package.
>
>That's on a machine where I haven't modified request-strictness from the
>defaults at all, though, so perhaps it doesn't count?

I have been investigating this lately, and that's another problem with
many variants/complaints, e.g. your bug #453935 or someone else's
#610845, hopefully it'll be addressed soon (but it's a problem going
back and forth for years, a trade-off between "ability to dist-upgrade",
"unattended-upgrades" and user's requests/expectations... so it's
difficult to balance).


This specific problem of this bug report about upgrading to experimental
might be different because the solutions using "non-default releases"
are placed in another level/tier, but the score that you were using is
only relevant within the same tier /nowadays/ (I don't know back then),
so no matter how much one changes the Source-Strictness it will not
cross the boundaries.

The question is if it considers all packages in "experimental" as
non-default and goes to another tier, all of them non-default except the
one requested to be installed in the command line, or all but the one
requested plus its dependencies that are necessary to upgrade (which
seems to be what you want here).

I am not sure if the last is a good idea in general, because there are
several complaints that aptitude is/was too eager to upgrade to
experimental when it shouldn't because experimental is very bad or
something, even when the submitters were requesting some packages to
upgrade to experimental in the same action.


(You probably know this, but as a workaround for people landing in this
page...)

For complex and infrequent solutions, rejecting some actions of the
first suggestions with 'r' in the solution screens/questions (both in
curses and in command line) would probably be enough to guide very
quickly towards a solution, in the absence of big problems like
transitions that make your request impossible to fulfill..

If the packages that one wants to upgrade are the same set causing
always problems, pinning those in particular might help
(apt_preferences).


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>