On Sun, 8 Mar 2009 16:29:29 +0100 Raphael Hertzog <hert...@debian.org> wrote:
> On Sun, 08 Mar 2009, Neil Williams wrote: > > dpkg --unpack needs to be able to work without executing any maintainer > > scripts, just > > extracting the data.tar.gz, decompressing the control.tar.gz, moving > > maintainer scripts > > to the var/lib/dpkg/info/ directory, handling var/lib/dpkg/status and > > var/lib/dpkg/available > > and leaving the status of the package as "Status: install ok unpacked" > > You're asking us to support crude hacks… --unpack is not --unpack if it > doesn't call the preinst/prerm. --unpack cannot operate if the architecture of the .deb does not match the architecture of the system. It is a fundamental requirement of any cross-architecture, even multi-architecture, system that no binaries are executed. It isn't a crude hack, it is a middle-stage between --unpack and --extract || --control and it underpins all operations in Debian that involve multiple architectures. It is still up to dpkg to sort out everything else via 'dpkg --configure -a' run on the target machine. This is an area of intense interest and activity around Debian, it would be a shame for dpkg to assume that native is the only supported system, particularly around installation support. > While I understand your need, I'm not convinced that dpkg has to be > modified to support this use case. After all policy compliant packages > have the right to expect in their postinst that the prerm/preinst have > been run. That will still happen, however, not until the binaries have been copied onto a system capable of executing them. The new mode would merely add a delay between tar -xzf and running the preinst sufficient to allow the files to be copied to a suitable system within that delay. All of these situations are based on debootstrap type environments where --force-depends --force-configure-any, --force-conflicts, --force-overwrite and --ignore-depends are likely to be in use. I don't mind if this new mode becomes a --force-foo *and* is only operative if the system architecture does not match the .deb architecture, i.e. needs to be used from outside what will become a chroot. > I fail to see why we would want to allow that. Hacks are okay to get > something done, but I wouldn't want to officialize hacks by integrating > them in dpkg itself. True, however there is more to dpkg than native-only. > I would suggest you to look into using virtualisation or other similar > solution instead. On an iPAQ?? Making cross-installation require Xen is a bizarre idea. > That's just my opinion. Maybe Guillem has some nicer approach to suggest, > we'll see. OK. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
pgpxWQjZEai7Z.pgp
Description: PGP signature
