[Aptitude-devel] Bug#833482: Bug#833482: aptitude: doesn't detect obsolete candidate package (versions)

Sat Aug 6 01:13:29 UTC 2016

Mhh... a bit further below in the text, aside from all the discussion
about whether this is supported or not,... I might have found some way
to go how aptitude could easily (at least semantically) identify
packages which are obsolete in the sense of: will this package (in the
current apt_preferences/sources.list config) still receive updates
(assuming that the repos themselves are still maintained) or not.

Not sure how difficult it would be to implement the abstract criterion
into actual code, though ;)

Anyway, if you're as tired about the political discussion whether
things is de jure / de facto supported or not, just skip on to (*).

If it would be easy to implement, you could either replace the current
"obsolete packages with it" (as I try to motivate below, it doesn't
make that much sense in the current form), or perhaps add it as a new
category, "packages that don't receive updates in the current config".

On Sat, 2016-08-06 at 01:12 +0100, Manuel A. Fernandez Montecelo wrote:
> The underlying problem is that you think that using Debian + external
> repositories which don't play well with Debian is a supported
> scenario.

Well "supported" is always a relative thing. It may not be supported in
the sense that someone from Debian feels officially responsible, but
it's actively and actually quite powerfully supported on the technical
side starting with sources.list allowing for multiple repos up to e.g.
the mechanisms of apt_preferences.

So why not making these situations safe, simply by properly telling
users when their packages won't receive anymore updates?

It's a bit cheeky to have all these mechanisms in Debian, actually
advertising them in the documentation, for quite a while even depending
on them (e.g. when DMO was the only resort to get usable multimedia
capabilities into Debian),... and on the same time saying: "nope, don't
want to properly (technically) support these functionalities).

At least I found no reference in the sources.list, apt_preferences or
aptitude manpages that things will be insecure in certain situations,
when multiple repos are used.

> "In most situations if you stick with one distribution you should use
> that and not mix packages from other distributions. Many common
> breakages arise due to people running a distribution and trying to
> install Debian packages from other distributions. The fact that they
> use the same formatting and name (.deb) does not make them
> inmediately
> compatible."

This quite clearly refers rather to the problems resulting from
dependencies than to package management software not properly detecting
situations in which software is really obsolete.

> (there are similar warnings about mixing different Debian
> distributions/suites except in completely compatible overlays, e.g.
> "security")

Well than why not hardcoding all these repos, and no longer allowing
people to configure them? Why not dropping apt_preferences if it's
anyway "not supported" and can just cause insecure situations?

> If DMO had transcode as a well supported package (perhaps packaging a
> maintained fork while keeping the same name, for example), it
> wouldn't
> be a security problem at all, you could switch to it instead.
Not if one has pinned it down via apt_preferences before.
Again, I really think that the question of whether DMO is well
[security]supported or not is completely out of question here.
And there are so many security questionable things in Debian, that it's
probably not appropriate to point at other "projects", either.

>   From
> aptitude's POV, it's not "obsolete", because it's present in other
> repo.
And as I've said, that's the problem.

Think about it this way:

What is the motivation behind having the knowledge "whether a package
is obsolete or not"?

If one hasn't installed it in the first place, then knowing that
package foo is now obsolete is pretty much useless from the package
management PoV.
Sure one can see: Debian has had this in the past, but not longer.
So what?

If one has it installed, what's the use of seeing that it's now
obsolete? I'd say either:
- To see that one can remove it safely in case of dependencies cannot
longer be fulfilled because of it.
- To notice that this is basically out-of-Debian-warranty (i.e no more
  updates - whether security or not).

The former case is probably largely irrelevant, either other packages
Conflict/Break/Replace/etc. the obsolete package already (and then I
don't need the info that's is obsolete) or they don't (and then I could
just keep the obsolete package if I don't care for security/new
versions).

So IMO the important case if the 2nd. Now just not getting new upstream
versions (with new features) is perhaps nice to know, but not knowing
it doesn't hurt one much either. If new features are missed people will
search and find out whether package foo is upstream-dead or just gone
from Debian.

In the end, what's really interesting about obsolete packages is:
package foo won't get any further security updates. If you continue to
use it, you're on your own.

This information is currently not available to aptitude users, when
they do *anything* that uses multiple repos, except those which are
fully aligned (e.g. stable + security updates).

> The fact that it was removed from unstable is not an indication that
> it's a security problem either.
Sure, but a) I haven't said that the status should indicate that there
*is* a security problem, but rather that an obsolete package won't get
any further updates (including security updates)... and b) in reality
it's quite likely for many packages that using a no longer updates
version will actually end up in security problems.

And as I've said just above... if one doesn't care about security
updates, than having the information whether something is obsolete or
not is pretty pointless. Either one hasn't installed it and then it's
simply gone... or one has it installed and can just happily continue to
use it.

> The only solution for this particular problem is DMO stopping to ship
> this package, if it indeed has security problems; and for this and
> the
> more general problem of packages dropping from repositories while
> present in others is you to monitor such packages, with the tools
> that
> aptitude gives to you (and Obsolete is the wrong tool in this case).

As I've said above, DMO (or any other repo) can't do anything about it,
when the user pinned down the packages from it to a very low priority.

I have e.g.:
Package: *
Pin: origin "deb-multimedia.org"
Pin-Priority: -1

and just selectively enable:
Package: libdvdcss2
Pin: release o=Unofficial Multimedia Packages
Pin-Priority: 500

Whether or not the DMO version is properly security maintained, doen't
matter at all, since my apt_preferences "disabled" it.
The Debian version however is kept, without any indication that it's
gone.

> It's not a security problem related to Debian or aptitude in any case
it is... the problem is that the definition of "Obsolete" as it is now
is pretty useless, or at least questionable with respect to security.

(*):
A simple (but AFAIU not really complete) workaround could be to define
"obsolete":
Package foo is obsolete, if the installed version is the same than the
canidate version, and if this version is only present locally.

Examples:

$ apt-cache policy mplayer
mplayer:
  Installed: 2:1.3.0-3
  Candidate: 2:1.3.0-3
  Version table:
     4:1.3.0~20160702.svn37873-dmo1 -1
         -1 http://deb-multimedia.org unstable/main amd64 Packages
 *** 2:1.3.0-3 500
        500 http://ftp.de.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status

=> all fine, versions are the same, but it's still in unstable/main

$ apt-cache policy mplayer
mplayer:
  Installed: 2:1.3.0-3
  Candidate: 3:2.3.0-3
  Version table:
     4:1.3.0~20160702.svn37873-dmo1 -1
         -1 http://deb-multimedia.org unstable/main amd64 Packages
     3:2.3.0-3 500
        500 http://ftp.de.debian.org/debian unstable/main amd64 Packages
 *** 2:1.3.0-3 500
        100 /var/lib/dpkg/status

=> installed version no longer in a remote repo,... but another
   candidate version is already selected (=> assuming that this will
   lead into a track that's kept up-to-date)

$ apt-cache policy mplayer
mplayer:
  Installed: 2:1.3.0-3
  Candidate: 2:1.3.0-3
  Version table:
     4:1.3.0~20160702.svn37873-dmo1 -1
         -1 http://deb-multimedia.org unstable/main amd64 Packages
 *** 2:1.3.0-3 500
        100 /var/lib/dpkg/status

=> no different candidate, and only left in /var/lib/dpkg/status.
   While there are repos left that have the package (DMO), their
   version is apparently not selected, thus one must assume that from
   the current apt_preferences config, mplayer is "obsolet" (in the
   sense of: it won't receive any updates)

The problem with this approach is:
Another the package/version combination from another repo could be
disabled via pinning and also have the same version number as the
installed one:
mplayer:
  Installed: 2:1.3.0-3
  Candidate: 2:1.3.0-3
  Version table:
 *** 2:1.3.0-3 500
         -1 http://deb-multimedia.org unstable/main amd64 Packages
        100 /var/lib/dpkg/status
=> BOOM! versions are the same, package still in a non-local repo, yet
   one won't get any updates to it.

Perhaps one can solve that with the priorities (but this has changed in
recent apt versions and I kinda miss the in-depth-insight):
E.g. if the local installed priority would be always 100, then one
could refine the above criterion to:
A package is obsolete (in the sense it won't get any further updates)
if all of the following applies:
- candidate version = installed version
- all available sources for that version are either local
  (/var/lib/dpkg/status) or have a priority lesser than (or equal to?)
  100.

> actual problem is that you think that you can use both unstable and
> DMO and report bugs as if it was a supported scenario ;)
:-P
You already do support this, or does aptitude bail out with an error if
it seems multiple different versions?

> https://backports.debian.org/FAQ/
> 
> Q: Is there security support for packages from backports.debian.org?
> 
> > >  A: Unfortunately not.
...
> > So, basically, mixing repos is not supported because it leads to this
> kind of problems, not even backports is 100% safe.
And yet there is backports and it's not just some experimental meadow
for fun but people do actually use it.

> > >  t's quite well known in the community, really.
Aha,... and yet it's there to be used?!

I think it's a bit cheeky if we say on the one hand:
- here are the backports, this makes your live so nice (which it does)
- have some small written notice somewhere which says "this is not
  supported", which people typically won't read at all and even if
  they'd do, not care simply because "everyone else" uses backports as
  well
- not warn (via package management) if things really run out of support

Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5930 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20160806/aea4b76a/attachment.bin>