[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation



On Jan 02, Axel Beckert <abe@debian.org> wrote:

> 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
As long as the needed patch is simple. But if it were, this would 
probably already have been solved.

>    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.
The abort notice should be provided by debconf before the upgrade 
process is started, indeed.

>    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.
I strongly recommend this solution, along with a proper debconf notice.
If screen is running, the admin will be able to choose between:
- abort the upgrade, upgrade screen and its dependencies and then 
  start again the full upgrade
- continue the upgrade while knowing that the old binary will still be
  available in /tmp/old-screen.$RANDOM/ or something

/tmp is a good choice because the next reboot will automatically clean 
up everything (and obviously the old binary will not be needed after 
a reboot).

>    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.
This would require a great amount of work to fix a tiny problem which 
presents itself just for the length of the upgrade process, if at all.

I believe that this is a textbook example which shows how trying to 
implement the perfect solution which will beautifully cover all corner 
cases has indefinitly stalled development on the package.
Do not try to fix everything, you should aim to provide a reasonable 
solution which will solve the most common cases.

-- 
ciao,
Marco

Attachment: signature.asc
Description: Digital signature


Reply to: