[OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade

[Chris Siebenmann]

> > Update Phase                              3141/16901Action upgrade failed for 'opt/gcc-4.8.1/lib/amd64/libstdc++.so.6.0.18-gdb.py' (pkg://omnios/developer/gcc48):
> > TypeError: 'NoneType' object is not callable
> 
> It's like you got an empty file for this one.

 I found the locus of the problem (I can't say I found the problem
itself). We have /opt as a separate ZFS filesystem, and here pkg update
is trying to update files in /opt in the new boot environment, which of
course only has the root filesystem and so is missing everything in /opt.
This appears to make some internal bits of pkg go badly off-course.

 Even if the pkg(5) code survived this particular mishap, updating
packages that live in /opt in a new boot environment is fatal in general
if the new boot environment does not actually contain the real /opt,
because pkg will create files and directories in /opt and then on
reboot ZFS will refuse to mount the 'real' /opt filesystem over the
newly-populated root filesystem /opt. As far as I can see there is no
simple way out of this (at least none that preserves the spirit of
separate boot environments).

 My modest proposal would be that pkg refuse to update packages with
paths outside the root filesystem if it's making a new boot environment.
If this causes the update to fail due to dependency issues, well, I
guess people get to clean things up by hand somehow (eg temporarily
remove the 'cannot be updated' packages, which pkg should obviously
report).

 What I think is happening in the code is that in
/usr/lib/python2.6/vendor-packages/pkg/actions/file.py part of
the check for 'do we need to actually install a new copy of this'
(in install()'s 'if do_content and ...' code) is whether or
not the file currently exists on disk. Since there is no (old)
/opt/gcc-4.8.1/lib/amd64/libstdc++.so.6.0.18-gdb.py file present
in the new boot environment, this check says 'yes, we need to' (in
needsdata()). However I suspect that earlier the code said 'no, we
don't need data for this, it's there on disk (in the real system)' so
didn't set up the FileAction object's self.data attribute since it
theoretically wasn't going to be needed.

	- cks