Danek Duvall writes:
> > * SUNWonbld currently uses a BASEDIR of /, and thus only installs into
> > /opt/onbld. I think it should use BASEDIR=/opt instead. Here's why: I
> > regularly install both SPARC and x86 packages on NFS servers with pkgadd
> > -a none (or an admin(4) file specifying e.g. /export/opt/$CPU as basedir
> > instead of /opt), so a SPARC file server can server software to both
> > architectures. With the current construction of SUNWonbld, this isn't
> > possible since the install scripts confuse BASEDIR (which is predefined
> > in pkginfo and can be overridden as above) with PKG_INSTALL_ROOT (which
> > comes from pkgadd -R <rootdir>) and install a couple of files relative to
> > $BASEDIR where $PKG_INSTALL_ROOT should be used. I had a patch to fix
> > this a year ago, and would like to see it integrated.
>
> Note that all architecture specific files in SUNWonbld are put into
> separate directories, so you can already add both i386 and sparc packages
> to a server and share /opt/onbld. In fact, that's exactly what I do on our
> gate machines, which serve these packages.
I see, and initially thought this would work. Then, I got confused by the
different revision info in the two packages:
SUNWonbld OS-Net Build Tools
(i386) 11.11,REV=2006.03.21.11.21
SUNWonbld OS-Net Build Tools
(sparc) 11.11,REV=2006.03.21.13.16
but of course this doesn't matter at all, and the packages are constructed
properly for ARCH={i386, sparc}. Further confusion was created by doing a
diff -r on the two unpacked SUNWonbld distrbutions where the pkgmap entries
for the shared files differ, but the change is only in the timestamps which
again doesn't matter.
I prefer to keep NFS-exported packages (which are generally os version
independent) out of /opt proper and install them into /export/opt/$ARCH
instead, that's why I proposed this change of BASEDIR.
> > * SUNWonbld should comply with Sun's own packaging guidelines and install
> > into /opt/SUNWonbld instead of /opt/onbld. This change requires a couple
> > of other places to be updated as well, but I've a list of affected files
> > and would obviously update them at the same time.
>
> I don't care too much, since I can just symlink this, but this is pretty
> hardcoded, and I don't think it buys anyone anything.
It's mainly a cleanliness issue: if there guidelines and conventions for
package names, OpenSolaris packages should be the first ones to follow them.
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
