[illumos-Developer] review: nuke staleness from svr4pkg

Garrett D'Amore garrett at nexenta.com
Thu Oct 14 23:36:24 PDT 2010


As part of the first round of changes where I'm giving some luvin' to
the SVR4 packaging command suite.  The first step is to trim a bunch of
legacy that is not needed (stuff that should have been done *years
ago*).

The webrev is here:

http://mexico.purplecow.org/gdamore/webrev/presvr4/

Specifically, what I've removed is:

a) support for checking against prodreg on pkgrm (it created a
dependency upon a closed, and I believe not-redistributable, bit of
code-- the admin consolidation.)  In short, we can't use that code.

b) support for "pre-SVR4" packaging.  This would have been used with
SunOS 4.x.  I've not seen such a package *ever*, even back in my SunOS
4.x administration days.  I don't know if it was *ever* used with
Solaris 2.x.  SVR4 packaging is about 20 years old now.  Do we really
care about what came *before* it?  Removing this also saves a bunch of
checks on each packaging operation, so the code will go faster with
fewer system calls.  (Yay.)

c) custom hacks for *patches*.  We will never, ever, ever support
partial package patching on illumos.  In fact, the problems with it are
the most oft-cited reason by the IPS team for throwing away SVR4 and
inventing something new.

d) support for the "special exceptional" WOS packages.  This was a
compiled in (well, it wasn't compiled in, it was #ifdef'd out!) list of
malformed packages in older releases of Solaris.  Its not been used
since S10 if the comments are to be believed, so I've just completed its
removal. :-)

e) support for the special older WOS packages that used internal
knowledge to generate a class action script to do compressed file
delivery.  There has never been a public tool to generate such packages,
and since at least Solaris 9 the packages in the WOS haven't needed it
because they ship with a more modern class action script (e.g. one that
can do bzip or 7zip.)

f) a "duplicate" header file for libadm.h.  The packaging tools can and
should just use the libadm.h from libadm itself.  (This did require
adding two missing prototypes to libadm.h.)

In total, this removes over 10% of the code for legacy packaging, and
greatly simplifies the code.  This is the first step towards
"modernizing" these tools so that they can be a viable alternative to
IPS.

	- Garrett




More information about the Developer mailing list