Call for feedback on a Ports-collection change

Max Laier max at
Thu Jan 8 17:33:58 PST 2004

On Friday 09 January 2004 01:49, Garance A Drosihn wrote:
> Especially as disks get ever-larger, I think we're
> better off with fewer-but-larger files, instead of a larger
> number of tiny files.

As disks get lager there is fewer concern about lost space (in my personal 
perception). If one is concered, however, she/he could keep /usr/ports on a 
seperate (smaler) partition and be okay. Not a compelling arument to change a 
working system.

> I would also write a single simple program, which knows how
> to find the correct info for any given purpose.  Thus, the
> format of the file should not be important.  The program
> would know what to do for both "old-style" and "new-style"
> ports, so we don't have to convert the entire collection
> at once.  I think the easiest and clearest way to implement
> this would be one C program, and not 800 lines of /bin/sh
> commands and deep make-magic.

You will never catch all the (crude) hacks spread all around the ports 
Makefiles and pkg-* with a "simple program". There are things like sed and 
friends messing all about the plist and I believe even worse hacks. There is 
a "simple program" to handle such things already - it's called make(1) and 
it's working well.

There are things that the "deep make-magic" could handle better, but that's 
something that can be adressed by hacking/cleaning-up and _not_ 
by writting something new (which introduces new problems).

> Does this seem like a reasonable project for me to pursue?
> Does it conflict with other projects which are already in
> the works to do a similar restructuring?  I wouldn't want
> to start this project if no one thinks it is worth doing.

IMO (which applies to the whole writting), it's a waste of time. The ports 
tree is - rightfully - precepted as "one of the best things about FreeBSD" 
and found entrance into the other *BSDs as well. Even Linux (gentoo) 
has /borrowed/ the idea.

As long as the only benefit is reduced disk usage you don't make a point (see 
above), plus you have to mind several things that will come as a consequence.

1) Changes are much harder to do:
With the currently used scheme it's fairly easy to add a patch when needed. Be 
it due to security issues, or just because -current moves a header, or 
whatsoever. With your change this will (at least) get more difficult.
2) Changes are much harder to track:
With the currently used scheme one can easily get information about what 
happend since the last version. Webcvs provides nice changelogs and with the framework these are easily accessed. With your change this 
will change as the changes might be spread all over the new big file and 
one'd have to read all through to get what really happend.
3) It will get harder to create ports:
Now you can just start with a very simple Makefile and see what happens, hack 
things to compile and clean up a bit (see the porters-handbook for an 
impersion of what I mean). With your newly created big-file system, this will 
be interrupted by syntax problems and endless scroll up/down sessions, just 
to back out the patch that just wasn't right ...

> [This message is BCC'ed to FreeBSD-arch, but I expect the
> discussion to happen on FreeBSD-ports]

I am not subscribed to -ports, but I'll keep track via web (no need to CC me - 

Best regards,				| max at
Max Laier				| ICQ #67774661	| mlaier at EFnet

More information about the freebsd-ports mailing list