Date: Mon, 14 Feb 2000 17:43:24 -0500 (EST) From: Trevor Johnson <trevor@jpj.net> To: Jeremy Lea <reg@FreeBSD.ORG> Cc: Richard Wackerbarth <rkw@dataplex.net>, Archie Cobbs <archie@whistle.com>, freebsd-ports@FreeBSD.ORG Subject: Re: /usr/ports/ too big? Message-ID: <Pine.BSI.4.21.0002141602030.4588-100000@blues.jpj.net> In-Reply-To: <20000212161556.D51878@shale.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Richard Wackerbarth wrote:
> On Thu, 10 Feb 2000, Archie Cobbs wrote:
> > Richard Wackerbarth writes:
> > > There are two problems in the size of the ports system.
> > > 1) The large number of inodes.
> >
> > I don't see the ports tree as the problem. The problem is that
> > FreeBSD does not handle a very large directory hierarchy like
> > that presented by the ports tree very well.
> >
> We HAVE to live in the house. The question is "how do we make the best
> use of the hand that was dealt us?"
I agree in part with Archie. When I've installed FreeBSD, unpacking an
empty ports tree onto an FFS filesystem without soft updates (which won't
be on because they're not in the GENERIC kernel, because of the license on
them) took much of the time for the installation, and I felt a bit
impatient while it ground away. I noticed that unpacking the ports
tarball on a Linux box onto an ext2 filesystem, even with synchronous
writes, finished up more quickly. I concluded that there was something
about there was something about the empty ports tree--most likely the
large number of small directories and files--that FreeBSD's FFS didn't
like much. We can "fix" the ports system so the empty tree contains fewer
files and directories, but there will still be situations where people
have numerous small files. One I've encountered was when I was the cache
Apache kept when I used it as an HTTP proxy.
There are other UNIX and UNIX-like filesystems besides FFS, and I expect
that FreeBSD's FFS will get better and better. If it doesn't, someone is
sure to make a fork. However, the main reason I see for installing the
whole ports tree is to be able to compile many ports, most likely as part
of one's own release. Someone who's doing that will be fetching the
distfiles (several gigabytes of mostly large files and a few directories,
with one enormous directory) and unpacking them (several gigabytes of
average-sized files and directories). For most people, I'd expect the
time needed to download the distfiles and compile everything will be much
more than the time needed to unpack the ports tree. Most people will only
be installing FreeBSD from scratch once or a few times per computer, and
most people should be able to go do something else while the ports tree is
being unpacked, or unpack it after setting up soft updates rather than
during the initial installation. If it's still a big ordeal, perhaps a
CD-ROM could be made with just the unpacked, empty ports tree on it.
People could mount the CD-ROM on /usr/ports/, then use the union
filesystem to download, unpack, and compile the distfiles "on top" of it
(I've not played with the union filesystem, but isn't it for things like
this?).
Jeremy Lea wrote:
> Personally, I like the idea of moving to a flat port 'delta'. Although
> I'd go two steps further, and make COMMENT the first line of DESCR and
> only have a single patch per port.
I like Jeremy's suggestions. I don't know whether it's just me, but I
find it easier to do something like:
$ tar xzf foo-1.0.tar.gz
$ cp -pPR foo-1.0/ foo-1.0.orig/
$ cd foo-1.0
$ make
$ vi Makefile
$ make
$ vi foo.c
...
$ make clean
$ cd ../foo-1.0.orig/
$ diff -ruN foo-1.0.orig/ foo-1.0/>foo-1.0.diff
rather than:
$ tar xzf foo-1.0.tar.gz
$ cd foo-1.0
$ make
$ cp -p Makefile Makefile.orig
$ vi Makefile
$ diff -u Makefile.orig Makefile>../patch-aa
$ cp -p foo.c foo.c.orig
$ diff -u foo.c.orig foo.c>../patch-ab
...
I may well be missing something, but the present way seems to make it more
difficult to use recursion.
Another place where COMMENT could perhaps be stuck is in the Makefile:
COMMENT= "Buzzword-enabled foo manager"
With these changess, a fairly typical port would go from:
/usr/ports/textproc/diffstat$ find .
.
./files
./files/md5
./patches
./patches/patch-aa
./patches/patch-ab
./Makefile
./pkg
./pkg/COMMENT
./pkg/DESCR
./pkg/PLIST
(11 inodes) to:
/usr/ports/textproc/diffstat$ find .
.
./md5
./diffstat.diff
./Makefile
./DESCR
./PLIST
(6 inodes). Using my other ports as examples, sapphire has 0 patches;
qrash, 21; and xmixer, 6, so for those there would be savings of 4 of 9,
24 of 30, and 9 of 15 inodes. Altogether, 23 inodes rather than 65 would
be needed for these ports.
__
Trevor Johnson
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.4.21.0002141602030.4588-100000>