<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Apr 4, 2007, at 3:14 AM, Randall Wood wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica Neue" size="3" style="font: 12.0px Helvetica Neue">The idea is this:</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica Neue; min-height: 14.0px"><BR></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica Neue" size="3" style="font: 12.0px Helvetica Neue">Stable and Unstable Ports trees available via both rsync and http</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica Neue; min-height: 14.0px"><BR></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica Neue" size="3" style="font: 12.0px Helvetica Neue">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.</FONT></P> </BLOCKQUOTE></DIV><BR><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>For those who didn't follow the whole remote index discussion way back when it happened, the general concepts were as follows:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>3. Assuming that a database can be contacted, "port install foo" then becomes:</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>3a). Dispatch a search query for foo</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>3b). foo is found (let's assume that) and its blob is sent back.</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>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.</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>3d). Clean up and remove the blob when finished.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>- Jordan</DIV><DIV><BR class="khtml-block-placeholder"></DIV></BODY></HTML>