Bug#649240: Bug#644788: Bug#649240: Upcoming upgrade issues with GNU Screen for Wheezy
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 <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: