Re: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
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
Reply to: