On Sun, Apr 03, 2016 at 09:32:19AM +0200, Robert Luberda wrote:
> Julian Andres Klode writes:
> > assume-yes causes *APT* to run non-interactively, not dpkg. It means that any
> > yes/no prompt *APT* shows will assume yes, except for the dangerous ones which
> > require one of the --allow-{downgrades,unauthenticated,...} switches formerly
> > known as --force-yes.
> >
> > should read something like:
> >
> > "[...] all <APT> prompts and run non-interactively (except for prompts from
> > other parts like debconf)"
The problem with that is: What the heck is "other parts" – I wouldn't
expect a lot of people to know that the lovely dialogs they see are
generated by debconf. Much like many can't tell the difference between
apt and dpkg. So, perhaps something like:
assume "yes" as answer to all prompts with the default answer yes.
This does not answer package configuration questions (debconf(7)) or
conffile prompts (dpkg(1)) as these are usually not simple yes/no
questions. If potentially dangerous or undesirable situations, such as
changing a held package, trying to install an unauthenticated package or
removing an essential package occurs then apt will abort if not
specifically allowed to continue with the relevant --allow-* flags.
Configuration Item: APT::Get::Assume-Yes.
It explicitly covers at least that non-interactivity isn't achieved by
-y. From the point of apt the interactivity is a "problem" of the
debian system, but given that apt doesn't really have another system (at
least not in mainline, there is the old rpm stuff…) nobody cares about
such details.
> So the question is: should apt-listchanges be treated as an "other
> part"? In my opinion: no. It is a plugin for APT, and it seems that
> people are expecting it to honour apt options and its non-interactive
> mode (see for example [1] or [2]).
The scripts are hooks, so from an apt point they are completely
different to apt and could have drastically different behavior – or the
same as apt, just like maintainer/users wish.
apt gives them the configuration space it worked with, so they can pick
and choose what to do, but there is no must in either direction.
apt can't and shouldn't enforce a certain behaviour as its unclear what
the behaviour should be: A random software-center (potentially via
packagekit) or python script calls the hooks just as apt, aptitude and
the GUIs like synaptic do. They all have a different way of interacting
with the user, so who am I to declare them all wrong expect my preferred
one?
The only "rule" I would like to enforce on hooks is that if feasable
they should be non-interactive. If they have to be interactive there
should be an option to make them not to.
> That's why apt-listchanges has been handling the `-q' option for the
> last 15 years (see bug#89511), and that's why I've recently added the
> support for the `-y' option (bug#687443).
Disclaimer: I have configured apt-listchanges to not ask for
confirmation (and which=both + a non-waiting browser so I have something
to read while waiting for apt to be done), so I am not exactly the right
person to ask here as all my hooks are in fact non-interactive all the
time…
That said, I can imagine usecases for all the suggested behaviors, so
I think its nice that there are options to bend apt-listchanges to
presumably everyones will and the documentation seems rather explicit
about it, so I see no reason to interfere even if I somehow had the
power to do so.
Best regards
David Kalnischkies
P.S.: @Roberto: The manpage has a typo in one of the envvars: Look
for FRONTED.
Attachment:
signature.asc
Description: PGP signature