An idea for distributing ports
Jordan K. Hubbard
jkh at brierdr.com
Thu Apr 5 03:00:26 PDT 2007
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
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
3. Assuming that a database can be contacted, "port install foo" then
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
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the macports-dev