Hi, Steve Langasek wrote: > On Sat, Nov 19, 2011 at 05:24:34PM +0000, Justin B Rye wrote: > > > Axel Beckert wrote: > > >> Possible suggestions for the release notes: Use tmux instead of screen > > >> for the dist-upgrade. Not really a laudable note for screen, but I > > >> have currently no better idea. > > > Would it make sense to recommend putting screen on hold
IMHO no. Most people won't read those recommendations. Besides I've never read such a recommendation before, neither for udev nor for gdm3. And I do read the release notes since approximately the Sarge/Etch dist-upgrade. > > and upgrading it separately after the dist-upgrade is finished? That's my current plan, but caused by a preconfigure or preinst script which fails if active screen sessions are running like udev did if it wasn't upgraded together with the kernel once. > > (We'll need material for the release notes eventually, but first > > screen 4.1.0 is obviously going to need to put some warnings and > > recommendations in a NEWS.Debian file.) Ehm, Justin, you seem not aware that there is already a "first" 4.1.0 package in Experimental which does exactly that: http://packages.qa.debian.org/s/screen/news/20111009T025041Z.html (Look for the string "NEWS".) The reason why I uploaded it to experimental and not to unstable is exactly the one we're now discussion about. :-) > Any such mitigation strategies will be a poor substitute for having screen > actually work properly across upgrades. Agreed. > There is nowhere that we can put such a recommendation that we can > ensure users will see it before they start the upgrade; Agreed. > and once they've started the upgrade inside of a screen session, > it's too late I disagree. > to put the package on hold Yes, it's to late for that, but not for that: > start the upgrade outside of screen / do anything at all except hope > you don't have to reattach to the screen to answer the > debconf/conffile prompts and complete the upgrade. Nope. It should do the trick if the 4.1.0 package fails to install very early in a way so that dpkg makes a rollback if the maintainer script encounters running screen sessions and then advises the user to wait with the screen upgrade until that session is finished. That's the way I currently plan to go. > Given that in other quarters I'm consistently hearing that screen has > stagnated and been overtaken by tmux, Well, it has stagnated if you take the average of several years, but it has taken up (a little) speed in the last two years with fresh blood in the team as it seems. I also disagree that it has been overtaken by tmux: I found tmux not really usable. That's why I took care of the slightly weathered screen package. But I know this opinion isn't the majority of people who tell things about screen and tmux. E.g. IMHO tmux' documentation doesn't help a lot. I wasn't able to implement something I did for screen in 10 minutes with tmux in 2 hours (and then I mostly gave up). > it's incredibly bad form for the new upstream version to have broken > protocol compatibility like this. I agree. > I think the screen maintainer should insist on upstream fixing > protocol compatibility before allowing this version into unstable. I'd be happy if you could write that on screen-devel. Best would be to reply to group-reply to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644788#22 I'm happy about everyone who helps to persuade upstream to fix that issue properly. :-) P.S.: I didn't get Justin's mail (yet). 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
