Re: Half-installed packages

[Havard Eidnes <he%NetBSD.org@localhost>]

> On Sat, Feb 28, 2009 at 10:36:27PM +0100, Havard Eidnes wrote:
> > I think this points to a lack of robustness in the package tools,
> > perhaps first and foremost in that pkg_add should not half-add a package
> > if something goes amiss during installation, but also that pkg_delete
> > ought to be able to cope with this sort of problem.
>
> I think you are confusing an important part here. pkg_add is not used
> for non-destdir installation, so it simply can't avoid/fix that issue.
> The only situation in which a reasonable current pkg_add should leave an
> uninstallable package in /var/db/pkg is when you reboot at the wrong
> time. There is a small window for that. pkg_delete doesn't and IMO
> shouldn't cope with that as it is a sign that your tree is quite
> corrupt, so every assumption it make can be a bad one.

I may be confused, but some of your assumptions are also wrong, so
please let me try to fill in a few more details:

I just posted a follow-up to my original message; I had another
similar occurrence of this problem on a machine running NetBSD/sparc64
used to do a traditional bulk build of the pkgsrc-2008Q4 branch.
There the symptom was that the chroot's /var/tmp filled up with
instmp.* directories to the tune of 22GB until the disk space on the
file system was exhausted.

Neither in that case or the originally reported case had the host
machine crashed during the build, so that cannot be used as an excuse
for the pkg_install tools for leaving a package in a half-installed
state.

To return back to the original problem, which was observed on
NetBSD/macppc 5.0 while doing the pkgsrc-2008Q4 branch bulk build:

while doing:

2009/02/25 08:11:52  5008/7743=64.7% emulators/suse100_base @ powerpc> 

I see:

=> Generating post-install file lists
=> Running POST-INSTALL script actions
suse_base-10.0nb5: rebuilding run-time library search paths database
[1]   Segmentation fault (core dumped) (/usr/pkg/emul/l...
suse_base-10.0nb5: populating /usr/pkg/emul/linux/dev
suse_base-10.0nb5: creating symlink /usr/pkg/emul/linux -> /emul/linux

That would be the INSTALL script trying to run the Linux ldconfig, and
since the kernel didn't have COMPAT_LINUX, that failed.

However, it still created the package:

===> Building binary package for suse_base-10.0nb5
=> Creating binary package 
/usr/pkgsrc/packages/powerpc/All/suse_base-10.0nb5.tgz

However, when the package is to be de-installed, I see:

=> Deinstalling suse_base-10.0nb5
suse_base-10.0nb5: removing /usr/pkg/emul/linux/dev
pkg_delete: unable to completely remove directory '/usr/pkg/emul/linux/etc'
pkg_delete: couldn't entirely delete package `suse_base-10.0nb5'

On the next attempt to operate on the suse_base package, I see:

ERROR: Empty PKGPATH for suse_base-10.0nb5

On the next attempt to pkg_add a package, I get:

BULK> Installing /usr/pkgsrc/packages/powerpc/All/teTeX-bin-3.0nb21.tgz
pkg_add: /var/db/pkg/suse_base-10.0nb5/+CONTENTS: No such file or directory
WARNING: could not add /usr/pkgsrc/packages/powerpc/All/teTeX-bin-3.0nb21.tgz.

and basically any pkg build in the bulk build past that point fails.

So I still think there is a lack of robustness in the versio of the
pkg_install tools used in these cases (the pkgsrc-2008Q4 version)
which manages to hose the bulk build in both these cases.

Regards,

- Håvard