Call for feedback on a Ports-collection change
max at love2party.net
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
> 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 bsd.port.mk 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
freshports.org 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 love2party.net
Max Laier | ICQ #67774661
http://pf4freebsd.love2party.net/ | mlaier at EFnet
More information about the freebsd-ports