[Aptitude-devel] Bug#768047: Bug#768047: aptitude: doesn't inform a user that a package will no longer receive updates when it obsolete in the target suite, but not yet for an older suite

Sat Jun 11 19:48:55 UTC 2016

Control: tags -1 + wontfix
Control: close -1

Hi,

Will not reply to all the details, the whole thread is quite unwieldy,
but some comments here and there:

2014-11-05 04:06 Axel Beckert:
>
>> Just because e.g. lcms1 is no longer upgraded in unstable, this
>> should mean that aptitude proposes it to downgrade to a "new" older
>> version, when a security update comes out.
>
>I disagree. Such a behaviour would be wrong and should be considered a
>bug if it appears with the default pinning. Changing aptitude's
>behaviour into that direction is solely a job for pinning (you can
>enforce downgrades through pinning if you really prefer that) and
>hence the local system administrator's job.
>
>The list of upgradable packages is controlled by pinning in similar
>ways. And I don't think that aptitude should override pinning (be it
>default or local) in any way unless the local admin overrides it
>interactively or on the commandline. (Which IMHO is easier to do with
>aptitude than with apt.)
>
>Additionally downgrades are officially _not_ supported, even if that
>downgrade may fix a security issue. Downgrades may or may not work
>(see e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764503#12)
>and I don't think, aptitude should by default suggest downgrades in a
>prominent way unless they are officially supported. And very often
>they are also impossible in the setup you described due dependency
>conflicts(*).

Downgrades are not supported in general, but specially Debian
maintainers never take "downgrade from unstable to stable" (or any other
downgrades) into account when thinking about scripts and dependencies,
so this is completely unsupported.

In general, unstable is unsupported, mixing several suites (except from
"overlays" like backports) more so, and downgrades are completely out of
question.

The scenario where it makes a bit of sense to have several suites is to
have e.g. stable as base and occasionally install things from testing or
unstable, but unstable being the main distro and installing things from
stable or other suites with lesser pin priority and smaller version is
an scenario for which the tools of Debian are not prepared to deal at
all.

If you tried to do that today with C++ libraries and the GCC-5 ABI
change of last summer, hell would break loose in your system.

So sorry, but your request is asking that the tools deal with scenarios
that are completely backwards compared to how they were designed.

So that's a +wontfix, and closing the issue.

>The security tag is debatable. The said feature may involve security
>updates under the circumstances you described. I know that this kind
>of setup is not that uncommon(*), but it's still very specific and
>especially _unsupported_. I still think we should not tag bug reports
>as security if they only involve unsupported setups (unstable with
>security updates from stable) and especially if they involve
>officially unsupported features (downgrading).

Agree.  There's nothing that the Security team would have done about
this, anyway.

2014-11-05 20:09 Christoph Anton Mitterer:
>
>But this is just the problem what we end up with:
>There is a package, which no longer receives updates, and of course, it
>won't and shouldn't (at least not automatically) receive the updates via
>the "deselected" stable suite... but it definitely should somehow tell
>the user what's going on (i.e. obsoleting the package/version
>combination).
>As otherwise, the user won't notice for a very very long time, that he
>runs a package which is potentially not security supported anymore.

That's a decision that the user takes when using unstable.

Security support for unstable is not there anyway, so if you install a
package only from unstable and it has security issues, you're not
guaranteed to get a security fix either.

>If this wouldn't be a corner case (i.e. the mixture of different
>suites/repos) I'd even set the security to something higher than
>critical),... but so I still think "important" is appropriate.
>Because as I've explained, this may also affect mixtures of different
>repos but same suite.

Different repos from Debian are not supported either, like "debian
multimedia" which were well known for having similar issues as mentioned
here.

>> The security tag is debatable. The said feature may involve security
>> updates under the circumstances you described. I know that this kind
>> of setup is not that uncommon(*), but it's still very specific and
>> especially _unsupported_.
>Is it? I mean I could imagine that mixing Debian's stable with unstable
>is _officially_ unsupported (even though it works quite fine in
>practise, and I guess it's not so rarely used)... but mixing Debian's
>stable with xyz's stable should be supported... not from the point that
>packages work with each other, but that you don't run into a situation
>as described here.

Since xyz's stable can have ABI incompatibilities, or a completely
different set of dependencies and conflicts, no, it's not supported
either; and since the version numbers are not agreed between Debian and
xyz, you can run into exactly the same issues (version in xyz higher and
without security updates, so updates from Debian are not taken into
account by the tools).

>In general it sounds interesting, but I don't think it solves the
>specific problem here, because the security issue described here, could
>also just happen the other way round (at least in theory), i.e. someone
>pins a package to stable, it's dropped from there or support because
>support is ended (something like iceweasel)... but it continues to
>remain in unstable, so the user would again not notice that he doesn't
>receive anymore updates.

That's another good reason why mixing suites in unsupported.

>And still, I think we should have a proper solution for this which by
>definition handles all possible corner cases (even such we don't see
>right now).

The solution is to adhere to which Debian explicitly provides and
supports, which is not bad for beign free, volunteer-based and so on.

All other uses are fine, but explicitly unsupported.

>Have you looked at my proposal of how "obsolete" should be defined in
>message #26? And what do you think about it?
>
>For me, that would be the natural meaning of "obsolete package" as I'd
>understand it based on common sense (and not on having to look up some
>definition).

The current definition matches common sense... it means that if aptitude
cannot see the version in the repository, it's either "obsolete" or
"local", and that's why they are grouped together.

Once a package is installed, aptitude doesn't know about the origin, so
unless package name and version matches one in the available set from
the given repositories, it's local/obsolete.

>But this, as well as your nice search string, is nothing that the
>average user will ever do (because he even doesn't think about this
>issue),... neither would automated tools like Nagios/Icinga's check_apt
>do.

For some definitions of average users, I don't think that you would find
an intersection between the set of "average users" and "users mixing
Debian stable and unstable" :)

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