Re: interesting question

2000-04-05 Thread Wichert Akkerman
Previously Joey Hess wrote:
> Hm. Would making a new, independant package that shiped out the broken
> package's prerm, and then making the new version of the broken package
> pre-depend on it work?

I think so.

Wichert.

-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


pgpKip1LrBEAl.pgp
Description: PGP signature


Re: interesting question

2000-04-04 Thread Julian Gilbey
Package: packaging-manual
Version: 3.1.1.1

On Tue, Apr 04, 2000 at 12:48:27PM -0700, Joey Hess wrote to -devel:
> Here's an interesting hypothetical question we came up with at the
> office:
> 
> Suppose a .deb is released that does rm -rf / in its prerm. We know it
> has been installed on a bunch of machines all over the place. How can we
> safely upgrade them?
> 
> [explanation of difficulty snipped]

I just wrote a long thought about similar problems, and then realised
that I didn't understand the packaging manual, section 6.3, para 1.

Could I suggest the following rewording to clarify the issue (which
more clearly describes the behaviour of dpkg):

-
  1. If a version the package is already installed, call 

   old-prerm upgrade new-version

-  2. If this gives an error (ie, a non-zero exit status), dpkg
- will attempt instead: 
+  2. If the script runs but exits with a non-zero exit status, dpkg
+ will attempt:

   new-prerm failed-upgrade old-version

  Error unwind, for both the above cases: 

   old-postinst abort-upgrade new-version
-

Still doesn't solve the problem Joey has, though.  I wonder whether
the possibility of having a "prerm-override" file would help, or
whether it would just complicate things unnecessarily.  Although I
could imagine situations in which non-malicious but still serious bugs
in prerm's could cause similar situations to arise.  Basically, in the
current setup, prerm bugs are mostly unfixable.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/



interesting question

2000-04-04 Thread Joey Hess
Here's an interesting hypothetical question we came up with at the
office:

Suppose a .deb is released that does rm -rf / in its prerm. We know it
has been installed on a bunch of machines all over the place. How can we
safely upgrade them?

I don't see any way to do it, because
/usr/doc/packaging-manual/packaging.html/ch-maintainerscripts.html
says that "old-prerm upgrade new-version" is the absolute first command
to be run during a package upgrade.

By contrast, if the rm -rf is in the old-postrm, the preinst of the new
package can whipe it out or something.

Note that in RPM, the preinst _and_ postinst are run before the
old-prerm and old-postrm. I emphasize that is _way_ broken, but it does
let this hypothetical situation be dealt with.


Hm. Would making a new, independant package that shiped out the broken
package's prerm, and then making the new version of the broken package
pre-depend on it work?

-- 
see shy jo