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

Sat Aug 6 03:16:07 UTC 2016

Hi,

2016-08-06 2:13 GMT+01:00 Christoph Anton Mitterer <calestyo at scientia.net>:
> 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.

I can only guess, but I think that the original motivation is that
when you use stable or unstable, if some package is classified as
Obsolete, is a reason to take special care about it, and so you can
freely delete it if you don't care; or if you care, add it again to
the archive (if was orphaned and deleted because it was an old version
with low popularity but it's OK otherwise).

This probably predates auto-installed, so it must have been a big deal
back then to clear cruft.  This doesn't mean that you don't have to
take an eye on other packages that you mix and match from different
sources.

So Obsolete/Local doesn't have any relation to "how secure is to use a
package or not".  It's "whether it's still downloadable from
somewhere" or "I could not find this package in any repo, but it's
installed in this system".  This maps quite direcly to other
functionalities, like "the changelogs are only available locally" or
"there are new changelogs in the server that the user might want to
see before installing".

Also, there's the peculiarity of testing, when packages are
auto-removed and then pop back again into life, in the last few years.
Each suite has its own peculiarities.  Obsolete is pretty useless for
this case of auto-removed packages.

On the topic of security, you can have installed v1.3.1~rc1 of a
package from experimental with dangerous bugs or security issues, and
v1.2.1 from unstable will not be installed (in most common
configurations), despite the risk for your system.  Obsolete in
aptitude and security don't have much to do with each other, it's only
an artifact of mixing distros and only one of a myriad ways in which
things can go obfuscated in terms of security when playing with
different distros, pinning, etc.

>> (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?

Beause in Debian we really like to give the option of shooting
themselves in the foot if they really insist on it.  Freedom and all
that.

We're not so keen on babysitting the users and monitor them with
twelve drones and raise an alarm in the police every time that they
step into a pond, which might be small pothole in the roadside or
might be a big lake.

Basically the contributors of Debian strive to support the most common
use cases, and it's hard enough, and a good enough gift to society, if
you ask me.

If people want to go playing around with our tools it's fine, but we
don't want to be healing them or paying the healthcare after hurting
themselves for using our tools in a way that we explicitly say that we
don't want to support, even if they go handwaving all around.

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

Since stable is the only suite that has guaranteed security updates,
all of your considerations before are not relevant.  unstable doesn't
have security support, testing doesn't either, external repos can
interfere with debian repos in ways that they take over, etc.

So your only relevant use-case for security is when using
stable+security, and there Obsoletes works well.

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

Actually, the way in which I have seen people to use Obsolete is
mainly to remove cruft, of packages that are no longer needed but are
marked as manually installed for some reason (bugs in aptitude/apt/etc
or not).

I never heard of people worried about obsolete packages in terms of
security, unless they are daemons or something special (often after
stable updated to next-stable).

Also, there's the peculiarity of testing, when packages are
auto-removed and then pop back again into life, in the last few years.
Each suite has its own peculiarities.  Obsolete is pretty useless for
this case of auto-removed packages.  But well, testing was out of the
picture at that time, auto-removals is relatively new and has low
impact, and can be removed at any time, so...

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

For aptitude it doesn't matter much what's in apt preferences.  You
can always select the version in the curses interface and install it.

Since the classification of "Obsolete/Local" is, again, whether the
version that you have it's only available in your system or whether it
can be installed from another repo, it seems only natural that if
there's another version from the package, it doesn't appear as
"obsolete/local".  Otherwise, how do you know that you can install
other versions?

One option would be to add an extra category, like "Upgradable",
"Installed", "Installed but in a different version".  This is easily
achievable with patterns and Views and other things, for people who
are into mixing distros.

It's a complication in many ways, and not very useful for the main
case that we want to support though, which is to use Stable, Testing
or Unstable.

That's why there's only two versions shown, "current" and "candidate".
It's assumed that you will either be up-to-date now, or will upgrade
when available.  aptitude never really intended to change the
interface in major ways for other cases, and doing so would be a
really major undertaking.

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

I think that the problem is again that you are repurposing what
Obsolete should mean instead of how it actually works and worked for
almost two decades, when the problem is basically that aptitude was
never thought for these cases.

I don't think that it's particularly compelling to change it in those
directions, and specially not with the reason of "security" -- it's a
very tangential issue for this matter.

> => 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)

See above: you can perfectly choose this version in aptitude's curses
to install.  Thus is not "local/obsolete", you can actually install it
from other repos.

Chaging the meaning after 15+ years is not the way to go.

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

Having the same package and version number is explicitly a recipe for
disaster in the apt world, so this is another unsupported scenario.
That's one of the reasons why DMO uses higher epochs -- to avoid this
problem (as well as "take over" the package).

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

It's the basic mantra in the free software world.

  $ ls --version
  ls (GNU coreutils) 8.25
  Copyright (C) 2016 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.

(the last line)

The fact that people spend their time in making your life better
doesn't mean that you can claim anything from them when things don't
turn out the way that you want or expect.

So maybe you should be a bit more grateful for the gift, rather than
blaming the people giving the gift away for not supporting a case well
enough (backports in this case).

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