cswpkgutil in Nexenta is not the same as Blastwave's

[Rob]

I discovered this issue while adding some info to this Report: https://bugs.launchpad.net/nexenta/+bug/350935

> Also affected: pkgtrans The workaround fixes the ...
Even with pkgtrans working I still have trouble installing Blastwave's "pkgutil_i386.pkg" Program, see
http://www.blastwave.org/howto.html

I am trying to install Blastwave's "libxml2" since the one in Nexenta is missing the "SUNW_1.3" type "libxml2.so.2",
see: http://www.blastwave.org/packages.php/libxml2

Here is the 'ldd' result:

# ldd /usr/share/lg3d/usr/share/lg3d/lib/solaris-i86pc/lg3d-x11/programs/Xserver/Xvfb
 libsocket.so.1 => /lib/libsocket.so.1
 libnsl.so.1 => /lib/libnsl.so.1
 libfreetype.so.6 => /usr/lib/libfreetype.so.6
 libz.so.1 => /usr/lib/libz.so.1
 libz.so.1 (SUNW_1.1) => (version not found)
 libm.so.2 => /lib/libm.so.2
 libXau.so.6 => /usr/lib/libXau.so.6
 libXau.so.6 (SUNW_1.1) => (version not found)
 libXdmcp.so.6 => /usr/lib/libXdmcp.so.6
 libXdmcp.so.6 (SUNW_1.1) => (version not found)
 libproject.so.1 => /usr/lib/libproject.so.1
 libc.so.1 => /lib/libc.so.1
 libmp.so.2 => /lib/libmp.so.2
 libmd.so.1 => /lib/libmd.so.1
 libscf.so.1 => /lib/libscf.so.1
 libgcc_s.so.1 => /lib/libgcc_s.so.1
 libsecdb.so.1 => /lib/libsecdb.so.1
 libproc.so.1 => /lib/libproc.so.1
 libpool.so.1 => /usr/lib/libpool.so.1
 libuutil.so.1 => /lib/libuutil.so.1
 libgen.so.1 => /lib/libgen.so.1
 librtld_db.so.1 => /lib/librtld_db.so.1
 libelf.so.1 => /lib/libelf.so.1
 libctf.so.1 => /lib/libctf.so.1
 libxml2.so.2 => /usr/lib/libxml2.so.2
 libxml2.so.2 (SUNW_1.3) => (version not found)
 libnvpair.so.1 => /lib/libnvpair.so.1
 libexacct.so.1 => /usr/lib/libexacct.so.1
 libpthread.so.1 => /lib/libpthread.so.1
 libiconv.so.2 => /lib/libiconv.so.2

Notice I need both "SUNW_1.1" and "SUNW_1.3" -- I use xfce as a Desktop so I hope I don't break that ...

# wget http://blastwave.network.com/csw/pkgutil_i386.pkg
# pkgadd -d /export/home/user/pkgutil_i386.pkg

822-date: warning: This program is deprecated. Please use 'date -R' instead.
822-date: warning: This program is deprecated. Please use 'date -R' instead.
cswpkgutil_1.5-rev2009.04.09-1_solaris-i386.deb generated
(Reading database ... 67632 files and directories currently installed.)
Preparing to replace cswpkgutil 1.5-rev2009.04.09-1 (using cswpkgutil_1.5-rev2009.04.09-1_solaris-i386.deb) ...
cmp: cannot open /etc/..//opt/csw/etc/pkgutil.conf
/bin/rm: cannot remove `/etc/..//opt/csw/etc/pkgutil.conf': No such file or directory
cmp: cannot open /etc/..//etc/opt/csw/pkgutil.conf
/bin/rm: cannot remove `/etc/..//etc/opt/csw/pkgutil.conf': No such file or directory
Unpacking replacement cswpkgutil ...
Setting up cswpkgutil (1.5-rev2009.04.09-1) ...
cp: cannot access /etc/..//opt/csw/etc/pkgutil.conf.CSW
cp: cannot access /etc/..//etc/opt/csw/pkgutil.conf.CSW

It would seem that Nexenta already has a 'cswpkgutil ' but it does not use the same directory
structure nor does it have all the same Programs as the Blastwave version does. Not good.

It seems odd that both Nexenta and Blastwave would use exactly the same name for the ".deb" file.
If Nexenta is purporting this to be a Nexenta-specific implementation then it needs to supply the
same programs and _might_ need to use the same directory structure.

I'll step back from that course of action and try the sources from (http://www.blastwave.org/packages.php/libxml2):
http://ftp.acc.umu.se/pub/gnome/sources/libxml2/2.6/libxml2-2.6.30.tar.bz2 -- I hope I can re-version my
creation and not have a conflict between the 'Nexenta libxml2.so.2 => /usr/lib/libxml2.so.2' and the
'Blastwave libxml2.so.2 (SUNW_1.3) => [with it's] (version not found) [message]'. Lots of work, should be fun.

Thanks if this (and these sort of issues) get(s) fixed,
Rob

[Rob (rob1weld)]

Much faster than rebuilding libxml2 is this hack!

A workaround (or "fix" if you do not hate the idea):

1. Boot OpenSolaris, since Nexenta is using snv_104 (uname says "NexentaOS_20081207")
   Try to choose a version of OpenSolaris equal or close to version snv_104. I used snv_106.
2. Tar.gz the OpenSolaris libs .
3. Transfer the tar.gz file to your Nexenta machine.
4. On Nexenta create /opt/sfw/libs and untar the files there.
5. Type "export set LD_LIBRARY_PATH=/opt/sfw/lib".

Result:

# ldd /usr/share/lg3d/usr/share/lg3d/lib/solaris-i86pc/lg3d-x11/programs/Xserver/Xvfb
 libsocket.so.1 => /opt/sfw/lib/32/libsocket.so.1
 libnsl.so.1 => /opt/sfw/lib/32/libnsl.so.1
 libfreetype.so.6 => /usr/lib/libfreetype.so.6
 libz.so.1 => /opt/sfw/lib/32/libz.so.1
 libm.so.2 => /opt/sfw/lib/32/libm.so.2
 libXau.so.6 => /usr/lib/libXau.so.6
 libXau.so.6 (SUNW_1.1) => (version not found)
 libXdmcp.so.6 => /usr/lib/libXdmcp.so.6
 libXdmcp.so.6 (SUNW_1.1) => (version not found)
 libproject.so.1 => /usr/lib/libproject.so.1
 libc.so.1 => /opt/sfw/lib/32/libc.so.1
 libmp.so.2 => /opt/sfw/lib/32/libmp.so.2
 libmd.so.1 => /opt/sfw/lib/32/libmd.so.1
 libscf.so.1 => /opt/sfw/lib/32/libscf.so.1
 libgcc_s.so.1 => /lib/libgcc_s.so.1
 libsecdb.so.1 => /opt/sfw/lib/32/libsecdb.so.1
 libproc.so.1 => /opt/sfw/lib/32/libproc.so.1
 libpool.so.1 => /usr/lib/libpool.so.1
 libuutil.so.1 => /opt/sfw/lib/32/libuutil.so.1
 libgen.so.1 => /opt/sfw/lib/32/libgen.so.1
 librtld_db.so.1 => /opt/sfw/lib/32/librtld_db.so.1
 libelf.so.1 => /opt/sfw/lib/32/libelf.so.1
 libctf.so.1 => /opt/sfw/lib/32/libctf.so.1
 libxml2.so.2 => /opt/sfw/lib/32/libxml2.so.2
 libnvpair.so.1 => /opt/sfw/lib/32/libnvpair.so.1
 libexacct.so.1 => /usr/lib/libexacct.so.1
 libpthread.so.1 => /opt/sfw/lib/32/libpthread.so.1

Notice the difference:
- libz.so.1 => /usr/lib/libz.so.1
- libz.so.1 (SUNW_1.1) => (version not found)
+ libz.so.1 => /opt/sfw/lib/32/libz.so.1
- libxml2.so.2 => /usr/lib/libxml2.so.2
- libxml2.so.2 (SUNW_1.3) => (version not found)
+ libxml2.so.2 => /opt/sfw/lib/32/libxml2.so.2

I missed tar-ing libXau.so.6 (SUNW_1.1) and libXdmcp.so.6 (SUNW_1.1) so I will
have to go back and get them. It looks like I am closer to getting this working.

I am able to start Firefox 3.0.5 to type this message and Nexenta seems to
work fine with this hack. Maybe this is a good idea, it did not seem that way
up until a minute ago ... If this did not work I'd expect a Kernel Panic.

Rob

[Rob (rob1weld)]

Here is Firefox running (almost) without using Nexenta libraries

# uname -a
SunOS nexenta 5.11 NexentaOS_20081207 i86pc i386 i86pc Solaris

# ldd /usr/lib/firefox-3.0.5/firefox
 libjemalloc.so => /usr/lib/firefox-3.0.5/../libjemalloc.so
 libpthread.so.1 => /opt/sfw/lib/libpthread.so.1
 libsocket.so.1 => /opt/sfw/lib/libsocket.so.1
 libdl.so.1 => /opt/sfw/lib/libdl.so.1
 libstdc++.so.6 => /usr/lib/firefox-3.0.5/../libstdc++.so.6
 libm.so.2 => /opt/sfw/lib/libm.so.2
 libgcc_s.so.1 => /lib/libgcc_s.so.1
 libc.so.1 => /opt/sfw/lib/libc.so.1
 libnsl.so.1 => /opt/sfw/lib/libnsl.so.1
 libmp.so.2 => /opt/sfw/lib/libmp.so.2
 libmd.so.1 => /opt/sfw/lib/libmd.so.1
 libscf.so.1 => /opt/sfw/lib/libscf.so.1
 libuutil.so.1 => /opt/sfw/lib/libuutil.so.1
 libgen.so.1 => /opt/sfw/lib/libgen.so.1

We should be able to run _some_ Sun binaries, _some_ Linux (Nexenta-ized) binaries
and I also have Sun Java SDK running (that works without this hack). I suggest that
Nexenta needs to have a portion of the OpenSolaris directory structure and libraries
and some of the Linux directory structure and libraries to maximize it's interoperability.

Rob

[Rob (rob1weld)]

This will also fix the grey boxes here: https://blueprints.launchpad.net/nexenta/+spec/hardy-release
shown on this link: http://img12.imageshack.us/img12/7379/ncp2hq9.png

On that point why mention Ubuntu, Debian is the upstream Operating System, Ubuntu is a fork.

Rob