On Mon, May 19, 2003 at 01:14:26AM -0500, David Young wrote:
> On Sun, May 18, 2003 at 09:47:01PM -0700, Jeff Rizzo wrote:
> > So, I just started playing around with syspkg the other day, and
> > it's got a lot of potential, but looks like it's suffered a little
> > bitrot since its initial commit over a year ago.  I noticed that
> > a few packages are referred to in the setlists that don't have
> > corresponding packages in the distrib/syspkg/sets directory.
> 
> Jeff,
> 
> I was bit by the missing directories bug, too. I use the attached script
> to detect, report, and create (with Makefile, and empty DESCR & COMMENT
> files) missing directories.

Thanks for that - the script looks like it has part of what I've
been doing, in a little more automated fashion.

> 
> If you are interested in whacking syspkg bugs, I have some pet ones:
> 
>     Add and delete a syspkg, and then verify that all the files were
>     actually deleted. I recall being disappointed.  I think because the
>     packing lists are written with the @dirrm and files out of order.

I haven't run into this one yet, mostly as I haven't really tried
deleting any syspkgs.  I'll watch for it, though, and see what I can
do.

> 
>     There seems to be an excess of leading /// in the packing lists.
>     It makes a difference, because the /// are compared textually some
>     places, not path-component by -component.

I'd noticed that.  I also noticed that when I did a 'make package'
for one of the missing syspkgs that I added, it complained about a
file which was missing in the root /etc dir, but was present in
$DESTDIR - but then it *did* include the file.

> 
>     The granularity of the lists is great big. I especially remember
>     some gigantic, non-essential files in /usr/share/ being grouped with
>     termcap files. There is not any notion of syspkg dependencies that
>     I can detect.

Heh.  Yeah, the termcap thing was one I noticed specifically. I
think that one deserves to be split up for sure.  There's also some
problems that aren't specific to syspkg - like that fact that
if you build with MKKERBEROS=no, it doesn't take that into account
in the set/syspkg-building process.  (or MKSHARE=no, or MKLINT=no,
etc)  I suspect that one involves more work.

Thanks for your feedback.

+j