Re: Bug#224509: [PROPOSAL] Correct spurious promise regarding TTY availability

[Tore Anderson <tore@linpro.no>]

* Manoj Srivastava

 > 	It is not a spurious promise -- this is accpeted
 >  practice. Violating this expectation results in unspecified
 >  behaviour.

  However, the only place (that I'm aware of) where this practice is
 documented, is in policy.  Joe User isn't, as far as I know, expected
 to be familiar with policy.  Yet he should be warned if he's about
 to do something seemingly innocent which could result in, as you put
 it, unspecified behaviour.

  Indeed, the way I noticed this was when I, with my Joe User hat on,
 tried to upgrade the package 'apt-listchanges' in an environment
 where /dev/tty wasn't available (from cron, to be specific).  It
 simply failed, without any warning.  I would classify that as a bug,
 irregardless of promises made by policy.  I'll grant that the
 question as to what exactly which piece is the buggy one, is more
 uncertain.

 > 	An thus such a radical change is beyond the scope of the
 >  policy process. First, one needs a rationale as to why this change
 >  is desirable, and then a plan as to how things are going to be
 >  transitioned.  Frankly, I do not see the benefits of this change; I
 >  am entirely willing to be educated.

  See near the end of this mail benefits/rationale.

  As for the transition plan -- I can picture something like this:

    1) debconf is changed to fall all the way back on noninteractive
       behaviour if necessary (see below)
    2) the change goes into policy and a note is added to the
       upgrading checklist
    3) affected packages are identified and bugs+patches are filed
       in the bts

  As for 3), I'm willing to do that.  I've got the feeling that not
 many packages are affected -- it appears to me it's mostly those
 packages that use both debconf and non-debconf interaction (such
 as ucf) in their postinst.  Those seem to be using /dev/tty out of
 necessity to work around #193694, not because using /dev/tty is
 the reccomended way anyway per policy 6.3 -- it is my impression
 that packages using -only- non-debconf interaction do generally
 not bother with /dev/tty, even though that's violating a should
 directive.

* Tore Anderson

 >>   Another thing worth noting is that the by far most popular method
 >>  for prompting users, debconf, already does the requred checking.

* Manoj Srivastava

 > 	That is a point in favour, which may allow us to accelerate
 >  the transition, since debconf is now the standard mechanism (still
 >  not a must directive).

  Hmm.  It seems debconf doesn't do quite enough checking.  I first
 tried "ssh localhost dpkg -i something.deb", where debconf did
 enough checking and finally fell back on using /dev/stdin.

  However, when running from cron it doesn't go all the way and
 assume noninteractive behaviour.  (I didn't notice that as I only
 upgrade packages through cron, which rarely makes use of debconf.)
 So debconf will have to be changed as well, if only slightly.

 > 	Why should we not just say "Don't install without a
 >  controlling tty for dpkg, as that is not supported", reflecting
 >  current practice?  What are the advantages of this change?

  Simply saying so would be an adequate solution, as far as I'm
 concerned, given that this is communicated clearly, which could
 be done for example by making dpkg refuse to run without a tty,
 unless a --force-notty parameter was given.

  However, I would prefer that policy and the problematic packages
 changed instead.  This is quite simply because prohibiting or
 discouraging running without a tty is limiting the user experience.

  For instance, I've regularily used our packaging system like
 this:

    * Automatic tracking of unstable on my developement box by using
      the 'cron-apt' package which, as its name implies, starts
      apt out of cron and makes it possible to do periodic,
      unattended upgrades.
    * Scheduling installations of DSAs at the farm of workstations
      at the office at night when nobody's using them, using at(1).
    * Doing "ssh somehost apt-get install foo" (or similar).  (Of
      course, this is easily remedied by using ssh's '-t' parameter,
      now that I am aware that a tty is required.)

  I've grown quite fond of these usages, and I had absolutely no
 idea that they were discouraged and unsuppported before one of them
 broke unexpectedly.  So running without a tty is a possibility I'd
 like to keep around and see properly supported.  That's why I
 feel whe should not just say "Don't install without a controlling
 tty for dpkg".

-- 
Tore Anderson