Date: Fri, 9 Jan 2004 11:13:35 -0800 From: Allan Bowhill <abowhill@blarg.net> To: freebsd-ports@freebsd.org Subject: Re: Call for feedback on a Ports-collection change Message-ID: <20040109191335.GA91968@kosmos.my.net> In-Reply-To: <p0602041abc1660a416d0@[128.113.24.47]> References: <p0602041abc1660a416d0@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
--ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 0, Garance A Drosihn <drosih@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 latest patches.=20 So unneccesary scaffolding is useless. Out-of-date uncessary=20 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 other targets. 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=20 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. --=20 Allan Bowhill abowhill@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 --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE//v1eBC/kSIeFE54RAn4gAJ4iCTo+H9kXCOBKgz14uP9Ae7vGswCfdJ25 l8OJLCFgVutydoppUEFfOF0= =i1zL -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040109191335.GA91968>