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 <a...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org