Bug#649240: Bug#644788: Upcoming upgrade issues with GNU Screen for Wheezy
Hi Justin,
Justin B Rye wrote:
> I should mention that I've got involved in this conversation because
> this issue was raised as a bugreport for the release-notes package,
> and thus copied to debian-doc:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649240
> http://lists.debian.org/debian-doc/2011/11/msg00004.html
Ah right, debian-doc is the owner of the release-notes package, not
debian-release (to which I'm subscribed). Thanks for the
clarification!
> Axel Beckert wrote:
> > Steve Langasek wrote:
> >> Justin B Rye wrote:
> >>> Would it make sense to recommend putting screen on hold
> >
> > IMHO no. Most people won't read those recommendations.
>
> Well, the people who don't read the warnings aren't relevant to the
> question of what warnings should be given. Of course if a solution is
> found that won't inconvenience people doing dist-upgrades,
I currently don't see any straight forward solution that does not
inconvenient those who want to do the dist-upgrade inside screen --
if upstream doesn't provide a solution.
> debian-doc can forget it.
Can forget what?
> I imagine the reason nobody recommended putting udev on hold is that
> it wouldn't have worked - too many things depend on it. For screen,
> things are different.
Ok. Putting screen on hold is just what the following would enforce
with more drastic measures. I guess the best variant would be to use
both.
> >>> 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.
>
> That can help block people from charging blindly into a situation
> where they've got lost screen sessions,
Exactly that's what it's for and unless there's a solution from
upstream, I think, it's inevitable. (Ok, there are other ideas like
renaming the binary package to something like screen410, but IMHO this
would pull in tons of other problems...)
> but won't it be at the cost of derailing a multi-package install
> with a sudden dpkg error message?
>From my experiences this works fine if a package with very few reverse
dependencies fails, but can cause big headaches if a package with many
reverse dependencies fail.
According to apt-rdepends -r, screen only has the following reverse
dependencies:
screen
Reverse Depends: apt-dater (0.8.6-1)
Reverse Depends: byobu (4.37-1)
Reverse Depends: cereal (0.24-1)
Reverse Depends: epoptes-client (0.3.1-1)
Reverse Depends: mdm (0.1.3-2)
Reverse Depends: podracer (1.4-1.1)
Reverse Depends: screenie (1.30.0-6)
(More than I expected though, I just knew of byobu and screenie.)
> If people were warned to upgrade screen as a separate process they
> could avoid either problem.
Or at least make the experience less sudden and unexpected.
> >>> (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".)
>
> Hurrah for NEWS.Debian and apt-listchanges!
I even got replies on the screen-devel ML due to this entry. Actually
such a mail revived that thread so I got that statement from upstream.
:-)
> > The reason why I uploaded it to experimental and not to unstable is
> > exactly the one we're now discussion about. :-)
>
> It doesn't actually offer a solution yet, though, does it?
Nope, because I wanted to wait for a statement from upstream, but
didn't want to hold back fixes for approx. 30 to 40 bugs. :-) This
statement came yesterday, but wasn't what I hoped for, so I pulled the
release team in.
> My point was that once there's a consensus it'll go there before it
> needs to go in the release notes.
Exactly. My mail to the release team was merely informational that
there's an issue which very likely will need an entry in the release
notes, but not what should be written there 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: