An idea for distributing ports

[Jordan K. Hubbard]

On Apr 4, 2007, at 3:14 AM, Randall Wood wrote:

> The idea is this:
>
> Stable and Unstable Ports trees available via both rsync and http
>
> Port currently works by grabbing info out of the port registry and  
> PortIndex file(s) on the local system and by looking at Portfiles  
> in the source trees whenever it is going to change the state of the  
> system by installing/uninstalling/activating/deactivating/whatever  
> a port.

I think this doesn't go far enough from where we currently are to  
justify the work involved.   I'm much more enthusiastic about taking  
Kevin's "remote index" idea to its logical conclusion and also,  
rather than thinking of things in terms of "stable and unstable  
branches", go to the more powerful model of port attributes which  
allows for "stability" to be just one possible search/selection  
criteria.

For those who didn't follow the whole remote index discussion way  
back when it happened, the general concepts were as follows:

1. dports/ as a hierarchy of directories and files goes away.   It is  
replaced by a flat "database" (at least conceptually - the back-end  
implementation of this database can be done any number of ways, from  
the crude to the impressive) of port blobs, where a "blob" is  
basically everything that currently exists in a port directory  
(Portfile + files/ dir) plus a set of attributes.  The most obvious  
attributes to start with would be name, version and category, but of  
course there could be any number (including "stable", "devel" or even  
"unreviewed"), limited only by pragmatism and imagination.

2. sources.conf lists one or more database sources, by http: URL.   
Since pretty much everyone's firewall allows http access, that gets  
around that particular problem, though other types of URLs could of  
course be supported (including, of course, a local database for  
disconnected operation).

3. Assuming that a database can be contacted, "port install foo" then  
becomes:
	3a). Dispatch a search query for foo
	3b). foo is found (let's assume that) and its blob is sent back.
	3c). The blob is unpacked and port walks in there to deal with the  
Portfile (and files/) just as it does today.  For all dependencies,  
of course, repeat steps 3a-3c recursively as needed.
	3d). Clean up and remove the blob when finished.

4. Now, since we have a database, other things become possible, such  
as "port submit".   Someone who wants to create a new port and make  
it available to everyone could, conceivably, go write that port, cd  
into its directory and say "port submit foo".  This would cause foo  
to be bundled into a blob and shipped off to the remote database,  
where it would probably (as a matter of policy) be tagged with the  
"unreviewed" attribute.   Anyone else with read access to this  
database could grab that port immediately thereafter and try it for  
themselves, so the database becomes a collaborative tool as well.

It's purely a policy decision, of course, but one could even allow  
for multiple "foos" to exist at the same time, adding some sort of  
disambiguating attribute, so that several people could submit foo  
ports and let the reviewers pick the best for stamping "reviewed".   
We've had people collide in the tree before (usually submitting the  
same port in two different categories), this would simply make that  
less traumatic.  Needless to say, another policy for "port submit  
foo" could also be to emit an error if a foo already existed and  
force the submitter to disambiguate it if they really had a good  
reason for submitting another port of foo.  However we want to go,  
it's fairly simple to implement the policy once all the other work is  
done.

Needless to say, if the database is sufficiently powerful to allow  
for multiple versions of foo to co-exist (and I see no reason why it  
wouldn't be), the need to maintain dports under svn also goes pretty  
much by the wayside.  The database IS an SCM tool unto itself at that  
point.

Also pretty much needless to say, a database means that the index is  
updated whenever something is submitted or has its attributes  
changed, so there's no need to manually recreate and check in a new  
PortIndex.

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070405/a1541325/attachment.html