Subject: Re: handling machine-dependent files in syspkg
To: None <email@example.com>
From: Jeff Rizzo <firstname.lastname@example.org>
Date: 05/19/2003 07:37:45
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.
> 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
> 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.