Control: tags -1 + pending - moreinfo
Both bugs #787658 and #714429 are manifestations of the same underlying
problem, and after thinking about this and diving into the code, I
decided that it is actually a bug and not a feature.
2015-09-19 12:50 To Christoph Anton Mitterer:
Now the problem from aptitude side is, that after the packages have been
downgraded
(in the example above the curl/libcurl packages) it doesn't offer them for
upgrade
anymore, even though unstable is still enabled in sources.list and the newer
packages
are still available.
[...]
Neither "Update package list", nor "Clean package cache" or "Clean obsolete
files"
resolves this situation.
But at least this time (I haven't tried that before), "Cancel pending actions"
plus
restarting solved the issue, and the packages re-appeared for upgrade.
So far (as said, I haven't tried the above before), the situation usually
resolved
by itself after a while (I susupect it did when really new Package lists came in
from the repo).
I think I have seen the whole issue even when packages where downgraded, but
when
I had already commented/disabled the "lower" repo (e.g. test) again.
Last but not least, since this may be "used" to accidentally hide security
upgrades,
I selected important as severity. I'd guess a higher severity is not needed,
since
downgrades typically don't happen automatically, so the admin has at least a
clue
that he runs on an older version.
I am not sure why it is behaving in this, if it's an explicit
design/implementation decision or by chance, but I would not be
surprised if this behaviour is intentional and it's there from the
start, or comes after complaints along the lines of:
"I want to keep this package downgraded and aptitude keeps nagging me
to upgrade it all the time... please make it stop".
I have seen lots of bug reports with similar complaints, not about a
specific issue, but in the same sense "aptitude is not smart enough to
second-guess my perfectly sensible intentions or follow my commands
exactly, and I have a good reason to choose what I chose".
I still think that this might be a problem and that we will get reports
asking to revert the new behaviour.
But after investigating it and thinking about it, I thought that using
downgrade+holds is probably good enough aproximation if people ask about
this (and hopefully now they work better and across apt as well).
After all, if one *actively* downgrades a package version, while one
doesn't update the package list, aptitude is doing what was requested:
keep the version that was specifically selected (against the default
recommendation, that keeps being the same one until new become
available). Maybe it's because that version is broken, or makes you
install 500GB of data that you don't want because of a mistake in the
packaging, so you know for sure that you don't want the newer version
until a new one fixing this becomes available. And when a new version
becomes available, it lets you know so you can decide again.
The fact that it doesn't show in the set of Upgradable packages is also
consistent with this "don't nag me all of the time". Picture this
user's rationale:
"It is in the list of Upgradable all of the time, so after pressing U
I still have to go to the N packages that I want to keep in the older
versions and select the old version *one by one*, *every day* when I
update testing / unstable / experimental. *Annoying*".
I also think that this may be a problem for somebody's usecase :)
So, in summary, I don't know if this is a bug or a feature (but I am
leaning towards the latter). It will need more investigation / thought
in any case.
As I said above, I think that the fact that it's not updating the state
after performing the action is a bug; but even worse is the effect that
it makes difficult to search for packages that were downgraded a while
ago, even with search patterns and the command line (bug #714429), there
seems to be no alternative to search for them other than going package
by package, which is not very good.
So in the end, marking as +pending, to be included in the next release.
Cheers.
--
Manuel A. Fernandez Montecelo <[email protected]>
_______________________________________________
Aptitude-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
