[Aptitude-devel] 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

Wed Nov 5 20:09:23 UTC 2014

Hey Axel

On Wed, 2014-11-05 at 05:06 +0100, Axel Beckert wrote: 
> AFAIK they actually _are_ the ultimate group to decided where the
> security tag applies to.
Well even though I see them behaving like that, I didn't found any place
where it's written... and actually some other people complained about
that as well... so I rather take "security" as "security" and not
"security-team" tag.

> It indeed seems as if you missed some facts:
> https://alioth.debian.org/project/memberlist.php?group_id=30020
> 
> You may also want to have a look at who signed the latest and some
> earlier uploads of aptitude: https://tracker.debian.org/pkg/aptitude
Ah,.. well I didn't see that,... just looked up the list at
packages.debian.org.

> And as long as I'm the only aptitude team member who has an opinion
> about this bug report, you should consider my opinion as being the
> maintainer's opinion -- and respect it accordingly.
Well nevertheless,... I still think it's rather impolite to change such
things without any further discussion.
Anyway... I guess discussing about this is a waste of time.

> > 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.
Argl... that happens when one answers to bugs so late in the night.

Of course I meant "this should *not* mean".
That was the whole point what I've tried to lay out:
aptitude should of course NOT override what I've set explicitly in the
apt_preferences mechanism and simply downgrade when it sees "oh there is
a security update which won't get into the users's target suite".

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.

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.

> 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.)
Sure... sorry for the confusion, by forgetting the "not"

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

> 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).
Well... I personally say, rather tag one too much than not. And I mean
"security" seems to not imply "security in an officially supported
setup"... I'd rather understand it via common sense as a general tag
"something that may somehow affect security".

And I guess no one is pointing publicly with the finger to you aptitude
maintainers, just because you have such a bug open?!

Anyway we're talking about useless formalities here... rather than the
issue itself.

> I though agree that having a group showing "newer than in archive"
> packages would be a helpful _feature_ in general.
mhh... "newer than in archive"... I probably need to think whether this
is what we actually want here...

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.

Now I don't think this ever happened so far, and one could argue like
Russ did in the other thread I've mentioned, that it's in the
responsibility of the user to read DSAs and get notified about problems
(at lets forget for the moment that there is in principle no secure way
of distributing DSAs).

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).
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).
And I guess it also takes into account the multi repo/suite scenarios
quite well.
For must users nothing would probably chance, and for those using
pinning,... they would actually see whether package+version combinations
are obsolete and not just packages

>  also because you already can
> search for according packages or limit the view to them as explained
> in my previous mail.
Well my point here is:
Of course you can. You can also just disable the stable repo (in my
example) for a moment, start aptitude and have a look what became
"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.

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