Re: Bug#677303: [RFR] templates://screen/{templates}
Hi Justin,
Justin B Rye wrote:
> Axel Beckert wrote:
> >>> -_Description: Previous screen binary has been copied to /tmp/screen-4.0.3
> >>> +_Description: Warning: upgrading screen with an active session
> >
> > I dislike this version as it reads as this is something which is
> > generally the case (which it is not). I though like the idea of the
> > word "Warning" in it.
> >
> > My suggestion: "Warning: upgrading to screen 4.1.0 with an active 4.0.3 session"
>
> Good if it'll fit; if not we might need to fall back on
>
> _Description: Warning - upgrading screen to an incompatible version
That's also a good idea!
> (No, forget that, yours fits.)
I actually like your version better. It easier to comprehend with less
words while still mentioning everything important, especiallt that
it's a one-time thing.
> >> (Last minute thought: does the second error message ever appear
> >> without being preceded by the first one?)
> >
> > Shouldn't. Both, config and preinst have the following code snippet:
> >
> > if cp -pnT /usr/bin/screen /tmp/screen-4.0.3 ; then
> > echo Copied /usr/bin/screen to /tmp/screen-4.0.3
> > db_input high screen/410-upgrade || true
> > db_go || true
> > else
> > echo Copying /usr/bin/screen to /tmp/screen-4.0.3 failed
> > db_input high screen/403-copy-failed || true
> > db_go || true
> > fi
>
> (Right, so users should only ever see one or the other, which means
> both templates do need to explain what's going on.)
I actually splitted it that way, because wanted the copying before the
debconf stuff so I can check its exit code. And that way the user just
has to press OK once.
> > But another thought: I posted a workaround for the worst case (dpkg
> > stuck inside unreachable screen, i.e. you can't run dpkg -i
> > screen_4.0.3*deb outside the screen and you don't want to kill it) at
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677227#5 -- would it
> > make sense to include this URL somehow? Or the workaround itself?
>
> It would make sense to point at a NEWS file with details and/or
> pointers;
Thanks for that idea! The NEWS entry is there since October with a
pointer to the initial discussion, but I can document the workaround
in there, so it's available locally on the system.
> debconf reviews often involve telling maintainers to move as
> much as possible into separate docs, but then again I can see how
> admins might prefer not to have to try to establish a new session just
> to read the README about problems establishing new sessions.
Well, yeah, the main reason for debconf here is to make sure the admin
is really aware of the issue because of its RC-ness.
> Of course, they'll all have read the Release Notes, right?
Yeah, sure. ;-)
> [...]
> >>> single physical character-based terminal. Each virtual terminal emulates a
> >>> DEC VT100 plus several ANSI X3.64 and ISO 2022 functions. Screen sessions
> >>> can be detached and resumed later on a different terminal.
> >>
> >> (While I'm here I'm imposing d-l-e "house style" single-spacing.)
> >
> > I thought double spacing is common for English (but not for German AFAIK).
>
> It's largely an en_US versus en_GB thing (my own habitual en_GB
> involves double-spacing),
Ah, ok, I didn't know that.
> but double spaces get squashed to single spaces anyway as soon as
> the description gets re-flowed.
I see.
> >>> configurable input and output translation, serial port support, configurable
> >>> logging, multi-user support, and utf8 charset support.
> >>
> >> Failing to support UTF-8 by default has been a bug since at least
> >> Lenny, so drop that one.
> >
> > Huh? Works fine for me, […]
>
> As far as I know screen's UTF-8 support is flawless (჻☽); and it's
> also FHS-compliant, Y2k-safe, and libc6-compatible, but these non-bugs
> no longer really count as features.
Ok, point taken. ツ
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: