[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: apt-get upgrade removing ifupdown on jessie→stretch upgrade



On Wed, Feb 22, 2017 at 09:04:16PM +0100, Luca Capello wrote:
> On Wed, 22 Feb 2017 13:16:27 +0100, David Kalnischkies wrote:
> > On Wed, Feb 22, 2017 at 01:06:24PM +1300, martin f krafft wrote:
> > > What am I not understanding right here? Shouldn't "apt-get upgrade"
> > > NEVER EVER EVER EVER remove something?
> [...]
> > Fun fact: We have a few reports which request "upgrade" to remove
> > packages. You know, automatically installed packages, obsolete ones or
> > obviously clear upgrades like exim4 to postfix (or the other way around,
> > depending on who reports it). I tend to be against that, but in case of
> > need we could still consider that a feature and close bugs… win-win :P
> 
> Please do not change the current behavior because...

JFTR: That wasn't really meant to be serious… as said I tend to be
against it for all sort of reasons, but even if not it would be hidden
behind config options and if enabled by default only for 'apt' as we did
e.g. with --with-new-pkgs. And yes, we haven't willingly implemented
that & I still can't really believe that it actually happened without
a LOT more details.

The funfact is more a comment on what people assume the current
behaviour to be based on either having formed an opinion of what
"upgrade" means by popular opinion (e.g. on a mailinglist) or learned by
experience (or documentation) that certain specific rules apply – one of
them being that no package is supposed to be removed in this mode.


But I don't have a good day today in terms of writing working
patches/mails so I can see how I failed here, too.
Too much carnival around me I guess.


> > Oh, and of course the standard reply: You know, apt does print
> > a proposal not an EULA – so you don't have to press 'yes' without
> > reading.
> 
> ...it will break existing practices, e.g.:
> 
>  DEBIAN_FRONTEND=noninteractive apt-get upgrade -y
> 
> FYI, I would call it a regression.

That specific invocation can "fail" for all sorts of interesting reasons
like dpkg config files or apt hooks. "fail" as in apt (and debconf) does
what it was told to do, but that doesn't say dpkg what it is supposed to
do. Or apt-list{changes,bugs} or …

Ignoring that reading the apt output even in such invocations isn't
a bad idea as it will e.g. tell you which packages it can't upgrade
– I kinda hope you aren't performing a release upgrade unattended…


Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature


Reply to: