On Jan 02, Axel Beckert <a...@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
signature.asc
Description: Digital signature
