Re: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

[Axel Beckert <abe@debian.org>]

Hi Yaroslav,

Yaroslav Halchenko wrote:
> pardon my blunt question:

No, this question is completely valid and understandable and came up
already in the two mentioned bug reports (#644788 and #649240).

> but is there really possibility to have them 'fixed'?

Well, there are several ways to "fix" this, some are surely less
perfect and less favourable solutions, but then again -- as you
correctly state -- the perfect ones may not be possible.

But we have to choose at least one solution because otherwise the
dist-upgrade to Wheezy will be very ugly (and therefor not
debian-like) for those who run it inside a screen session remotely and
the network connections dies after screen has been dist-upgraded. (So
IMHO there is no option to do nothing at all. ;-)

> I am reading upstream response just as a statement that it can't be
> achieved due to a chance in protocol...

Yep.

I see the following options:

A) Add an option to screen so the screen client speaks the old
   protocol to the running server protocol. This IMHO would be best
   solution and one without a big impact. It's also something which
   could be Debian-only, i.e. a patch. (It of course would be better
   if upstream could be convinced to add such an option. :-)

B) Take care that nobody upgrades the screen package while running
   inside a screen without being aware of the possible problems. There
   are few ideas how to implement this:

   1) Mention it in the release notes that screen has to be upgraded
      to the very end of the dist-upgrade process if the dist-upgrade
      is running inside screen.

      Disadvantage: Many admins don't read the release notes.

   2) Fail in the preinst maintainer script if screen server processes
      are running like udev did from Etch to Lenny if not upgraded
      together with the kernel.

      Disadvantage: According to Steve Langasek this could be very
      ugly, so I suggest to inform via debconf about the issue and let
      the user decide if he wants to continue, abort (or maybe get a
      shell to connect to that screen session and close it)

   3) Tell people via the release notes that they should not run the
      dist-upgrade inside screen, but inside tmux instead.

      Disadvantage: Many admins don't read the release notes. People
      may still distrust tmux for such an crucial task or just may not
      be comfortable with the parts where tmux's behaviour differs
      from screen's behaviour.

C) Provide both, screen 4.0.3 and screen 4.1.0 binaries. Again, here
   are more than one option to do so:

   1) Let the preinst maintainer script make a copy of the old screen
      binary, provide a script to clean up this mess afterwards,
      inform the user via debconf about the issue and his
      possibilities (where the copy of the old screen is, etc.).

      Disadvantage: It's a non-dpkg-managed mess.

   2) Make screen 4.0.3 and screen 4.1.0 installable at the same time,
      i.e. give them different source and binary package names.

      Disadvantage: Dependencies between those packages needed for
      proper Wheezy migration not obvious. We'd need something like
      "if screen sessions are running, pull in screen-4.0.3 and
      screen-4.1.0, but just pull in screen-4.1.0 if no screen session
      is running", but of course this is impossible just with
      dependencies.

Additionally, I'm not 100% (but let's say 90% :-) convinced that these
changes necessarily had to be incompatible. But changing them back (if
possible) would surely have some impact the other way round for those
already running git snapshots running with the current protocol
version. So there may be also an option "D":

D) Convince upstream to make the new protocol (which includes password
   protected screen sessions even after reattaching) compatible to the
   old protocol.

IMHO option A would be the most preferable one, D seems less
realistic, C2 is realistic but quite some work, B1, B3 and C1 are
ugly, and B2 is said to possibly become ugly, too.

So my current plan is that if nobody manages A, I'd have a closer look
at C2 and if that's not possible or too complicated, I'd go with B2
and the mentioned Debconf questions as the last resort.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5