Call for feedback on a Ports-collection change
abowhill at blarg.net
Fri Jan 9 11:16:10 PST 2004
On 0, Garance A Drosihn <drosih at rpi.edu> wrote:
:What I want to do is create one new file per port, and then
:move almost all the other files into that new file. Ideally
:each port would end up with just two files. The Makefile,
:and this new file (some ports might also need a Makefile.inc
:file). 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.
: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.
: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.
The one file-per-port idea gets discussed at times, usually with XML
as the proposed file format. What you are talking about sounds similar.
You could revise the current system, but from my perspective, it sounds
like another kludge to an already somewhat overengineered system. If you
are going to make a change this radical, why not go further than this,
and just design an all around better ports system?
The inode problem is legitimate in terms of updating. And if you really
think about it the cure for inode clutter is simply not to distribute
the whole physical ports tree to anyone's disk in the first place.
Since network connectivity is required to use ports anyway, it doesn't
make sense to have a lot of build scaffolding in place for so many
programs most people will never use.
Ports usage is very mission-oriented. For example, I as a user, browse,
select and install. 90 percent of what exists in my /usr/ports tree will
never be installed. And when I enter the ports tree to install a version
of soemthing, I usually ask myself: when's the last time I cvsupped?
Then I usually end up going into /usr/src and updating to get the
So unneccesary scaffolding is useless. Out-of-date uncessary
scaffolding is time-consuming.
The whole problem suggests virtualization of the ports tree somehow,
keeping unused and stale data on a user's disk to a minimum.
A somewhat standard approach would be to store all port data in a
centralized, network-accessible relational database. Ports tables could
be updated from version control at a central server. The online
databases could serve client requests, directly or indirectly
from userland machines.
A userland client could be some program like a ports command shell.
You don't want some knob-laden monstrosity like RPM to fetch and
install and programs, but something that emulates the behaviour of
the ports tree as it stands now.
The user should be able to browse the tree over the network, search and
select ports much in same the way directory navigation works.
When "make" is issued, the shell would fetch the port's XML file from
the server, (provided dynamically by some backend database query) un-
archive in the right place in /usr/ports, and proceed as normal with the
Some general scaffolding on user's machines would have to pre-exist, as
it does now, and some would accumulate with use.
A Ports database, afaik, has already been in existence for a few years.
(http://www.freshports.org). I don't know what their position is
on sharing their design and tools.
Anyway, there are lots of design possibilities, but if you want to make
big changes, go all the way with it. Build a prototype, demo it, and
sell people on adopting it.
abowhill at blarg.net
I don't care for the Sugar Smacks commercial. I don't like the idea of
a frog jumping on my Breakfast.
-- Lowell, Chicago Reader 10/15/82
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20040109/6620b968/attachment-0001.bin
More information about the freebsd-ports