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 <sgunder...@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.montez...@gmail.com>
