* David Kalnischkies [Wed Feb 22, 2017 at 10:28:33PM +0100]:
> On Wed, Feb 22, 2017 at 09:04:16PM +0100, Luca Capello wrote:
> > ...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 …
With the according options all of that can be controlled as needed, e.g.:
APT_LISTBUGS_FRONTEND=none
APT_LISTCHANGES_FRONTEND=none
APT_PARAMS="--no-install-recommends -y -o DPkg::Options::=--force-confask -o DPkg::Options::=--force-confdef -o DPkg::Options::=--force-confmiss -o DPkg::Options::=--force-confnew"
DEBIAN_FRONTEND=noninteractive
(Disclaimer: especially the quoted "APT_PARAMS" is highly
environment specific of course and the environment variable is just
named by me/us as such. I know that you - David - know all of that
and that you wrote "[with] That specific invocation can "fail", so
consider it JFTR :))
> 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…
Several customers of mine have fully automated upgrade procedures,
without any manual intervention needed and I'm sure there are
several other folks doing similar stuff. In big environments with
many systems and also products based on Debian which require easy
upgrade procedures (possibly even by the enduser) I'm actually
expecting to see such practices, since the process to get there can
be automated + tested in advance (that's what we're doing).
regards,
-mika-
Attachment:
signature.asc
Description: Digital signature