Can I please get some eyes to review this change request again? http://cr.opensolaris.org/~tsk/863/
The main difference between this one and the old webrev is that: - the name of the python -> C library has change names and is now libbe.so - importing the library is done dynamically. If it exists it is imported, if not it isn't. This allows pkg(1) to not hard require SUNWinstall-libs which delivers libbe.so and also allows pkg(1) to exist on systems that SUNWinstall-libs will not be installed on. I think I handled all the previous concerns however I didn't implement a test case for verifying that the code does the right thing on UFS since this requires file system changes that don't seem appropriate for a test suite that can be run on non test systems. Rest assured though that I tested this manually and it works fine. i.e. If the directory /<pool>/ROOT/<beName> exists on UFS the recovery is disabled. Thanks Tim Tim Knitter wrote: > > > Tim Knitter wrote: >> >> >> Stephen Hahn wrote: >>> * Tim Knitter <[EMAIL PROTECTED]> [2008-03-28 21:46]: >>>> >>>> Stephen Hahn wrote: >>>>> * Tim Knitter <[EMAIL PROTECTED]> [2008-03-28 16:59]: >>>>>>> 3. Do you have ideas on how to make this portable to older >>>>>>> Solaris releases and non-Solaris environments (Linux, Windows, >>>>>>> etc.)? I'm >>>>>> It is all based on the supported namespace <pool>/ROOT/<beName> >>>>>> existing and it being a zfs dataset. So if either of those don't >>>>>> exist then no recovery will happen. >>>>> Is the "it being a zfs dataset" test really "it being a zfs dataset >>>>> with the specific new feature we need", or is it not able to >>>>> determine >>>> The "it being a zfs dataset" refers to the target image. Either the >>>> live system or the argument to pkg -R. If either of those resolve to >>>> a zfs dataset resembling <pool>/ROOT/<beName> then recovery is >>>> enabled. The specific new feature pkg(1) needs is the knowledge of >>>> the namespace layout and the existence of libbe. I hope that >>>> answered your question. >>> >>> I had thought that libbe relies on ZFS behaviour introduced after >>> Build 79. Will a DP2 build (which has rpool/ROOT/preview2 as a >>> pattern, but is Build 79 based) actually be able to run pkg/libbe >>> correctly? >>> >> >> The correct behavior of libbe relies on ZFS features introduce after >> build 79. So the answer is a sad no. I'm going to request that libbe >> provide an interface so libbe_glue and friends can query about the >> availability of full functionality. >> > > After discussing this with Ethan it doesn't appear that this will work. > There currently isn't a way for libbe to determine from libzfs if post > 86 bits are installed. > > So updating P2 to P3 will still need to be done manually. We will need > instructions similar to the ones on opensolaris: > http://opensolaris.org/os/project/indiana/resources/update_guidelines . > These instructions mention that the P2 version of SUNWipkg be installed > before cloning at step 3.3. In order to allow this to happen for P2 -> > P3, pkg(1) can't hard require the libbe_glue package SUNWinstall-libs, > since SUNWinstall-libs requires SUNWzfs* which requires SUNWcsr and that > will suck over incompatible changes. So I made pkg(1) dynamically import > libbe_glue.so if it exists so we can get around this snafu. So after > installing the P3 version of SUNWipkg on a P2 system, as described at > step 8, and running the pkg -R /mnt image-update command, libbe_glue.so > won't exist and no built-in recovery will be attempted allowing the > image-update to succeed. Once the user reboots to their P3 system > built-in recovery will be enabled and then going from P3 -> P4 will be > handled by pkg image-update without special instructions. > >>> We expect to be able to upgrade from DP2 to the next release, so this >>> is a required (presumably manual) test case. >>> >> >> We would either have to automatically install the required zfs >> packages and possible dependent packages or have the user do it before >> image-updating, ugh. I need to verify that that is even a viable >> workaround for DP2 though... >> > > This is not viable as mentioned above. > > Thanks > Tim > >> Thanks >> Tim >> >>> Thanks >>> Stephen >>> >> > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
