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

Sat May 14 14:45:35 UTC 2016

Control: tags -1 - moreinfo
Control: close -1 

Hi,

2016-03-18 12:15 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).

The bugs above have been closed in 0.8-1, hopefully the solutions now
are much better by default.

>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.

Still with these changes in 0.8, when the solution implies upgrading
other packages, it sometimes invokes the resolver, and the first
solutions are to keep or to upgrade to other versions (e.g. unstable or
testing, if they are the default and the packages are not up-to-date),
not to experimental.  This depends on number of packages being changed
and many other variables that the full resolver takes into account, so
different cases can vary.

I think that it's undesirable in general to have the first suggestions
including upgrades of experimental (or other suites, including external
repositories) of packages unrelated with the one requested to be
upgraded.  For example, if one package in experimental or an external
repo depends on glibc or other tricky packages from experimental /
external-repo, maybe the results after upgrading are not the best ones,
and there can be other issues [*].

If aptitude starts to suggest this by default I'm quite sure that we'll
soon hear from angry users (we already do sometimes, even if it's not
one of the first suggestions).

[*] Even leaving aside big breakages, packages in experimental are often
    neglected, so it's not always a good idea to suggest upgrades
    lightly.

    For example I just attempted to upgrade "kio" as a means to test how
    upgrades to experimental work today when reconsidering this bug.  It
    turns out that I would have to install "libpng12-0" even if the
    transition to libpng 1.6 happened a few weeks ago, presumably
    because libqt5gui5 in experimental was compiled with libpng12 before
    that, and did not take part of the transition.

    Security issues in neglected packages of experimental can also be an
    problem.  Packages in unstable are sometimes more up to date and fix
    security issues that packages uploaded to experimental and then
    forgotten do not address.

    It's true that if users want a specific package from experimental,
    it's up to them.  The problem is when there are other packages
    pulled in due to dependencies, and the users are not [sufficiently]
    made aware of those necessary upgrades alongside.

Since:

>(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).

... and ...

2016-03-18 16:42 Manuel A. Fernandez Montecelo:
>2016-03-18 12:30 GMT+00:00 Steinar H. Gunderson <sgunderson at bigfoot.com>:
>>
>> I don't think I've ever used 'r'; I've just used 'n'. I wasn't aware that
>> you could do much more than just ask for the next solution.
>
>I mentioned it, just in case.
>
>  http://aptitude.alioth.debian.org/doc/en/ch02s03s03.html
>
>Basically, you can 'r'eject and 'a'pprove some of the solutions (or,
>since the last version 0.7.8, to whole subtrees like 'r' to "remove
>the following packages" or 'a' to accept "packages to be upgraded"),
>so these will disappear from solutions offered which have not been
>generated yet... and so you converge quicker to the solution that you
>are looking for.

... I think that this is the best solution, for cases when upgrades are
tricky, like this case.  The user is shown that the upgrade of several
packages to experimental/etc is required, has to think a bit about it
(but just a few seconds, nothing too demanding) and confirm the actions.

Another possibility is pinning, when the set of packages in experimental
which are upgraded frequently is known -- so aptitude/apt are more
amenable to upgrade to the versions in experimental for the limited set.

So after almost a decade open, I am going to close this bug, I think
that further changes of the resolver for this reason would not be
positive.

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