[illumos-Developer] review: nuke staleness from svr4pkg

Garrett D'Amore garrett at damore.org
Sun Oct 17 14:53:09 PDT 2010


On Sun, 2010-10-17 at 21:43 +0100, Peter Tribble wrote:
> On Fri, Oct 15, 2010 at 7:36 AM, Garrett D'Amore <garrett at nexenta.com> wrote:
> > 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/
> 
> psvr4ck.c? The webrev indicates it just contains "/*" rather than just
> being wiped.

Oops.

> 
> libadm/pkginfo.c has a Nexenta copyright. Nothing against that, but
> why just that file?

It was one file... I'll probably add it to others *if* I add
functionality or make non-obvious changes.  I probably should remove it
from this file, since all I did we was remove functionality.

> 
> In package-svr4.mf you've removed the line
> hardlink path=usr/sadm/install/scripts/i.CONFIG.prsv
> why?

Nothing was using it, and the Makefile to create it is removed.  I have
no idea why it was ever delivered in the first place.

> 
> You've removed the SUNOS41 check from pkgremove/check.c - there are
> a bunch of other checks (one in pkgtrans/main.c, something like 15 in libpkg,
> aanother one in libadm). If you're going to kill it in one place, why not finish
> the job?

Ah, I just noticed that one in particular.  I didn't go on a hunt.  I'll
do that now though.

> 
> > 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.
> 
> Something useless and can be a significant performance hit. (And one
> reason I built my own fork, just to kill it, because it's actually broken.)
> 
> > 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.)
> 
> You've missed pgknmchk.c in libadm (although see later for libadm)

Ok, I'll check into it..  If there are other places I can clean stuff
up, I'd like to. :-)

> 
> Actually, I think this was SVR3 packaging; that's a different evolutionary
> track to SunOS 4.x. I planned to do this several years ago, before the
> install consolidation stopped releasing code drops. The feeling then was
> that even if you could install such a package (and the chances are that
> it would just break anyway, not having been tested in over a decade and
> lots of other changes having been made), none of the software contained
> in it would work anyway.

Oh wow.  Well, its best removed in any case.

> 
> > 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.)
> 
> Not a code review comment, but I believe this to be the wrong approach.
> I think you want to kill libadm and if there's any functionality you need,
> then bring it across to the packaging code directly.
> 

There are other programs (fstype?) that use libadm.

In fact, I'd like to gut the whole device.tab thing, but that's another
windmill for a different day.  If/when we tackle that, *then* I'll gut
libadm most likely. ;-)

	- Garrett




More information about the Developer mailing list