Proposal for a new repository layout

Randall Wood rhwood at mac.com
Wed Apr 25 09:34:35 PDT 2007


On Wednesday, April 25, 2007, at 07:25AM, "Paul Guyot" <pguyot at kallisys.net> wrote:
>On Apr 25, 2007, at 9:02 AM, Ryan Schmidt wrote:
>
>>> 	I propose we start with those two trees and fill them up as  
>>> necessary, the first one being the existing trunk/dports which  
>>> would *have* to stay in sync with base/branches/release_x_y and  
>>> the second being a testbed for Portfiles that need unreleased  
>>> features and syntax to function (ports would be added to it as  
>>> needed, no need to mirror every single category and port in ports/ 
>>> released if the corresponding Portfile doesn't pack anything  
>>> different). I would like to make clear that our released Vs.  
>>> testing split would be with respect to our *Portfiles* and not to  
>>> the projects we port; that is, emacs and emacs-devel would still  
>>> be in the released tree as long as their Portfiles are in sync  
>>> with MacPorts released code. This is contrary to the a la Fink  
>>> "stable" Vs. "unstable" model, which we all know condemns stable  
>>> to always be incredibly out of date and pushes everyone to use the  
>>> unstable tree, while alerting users their computers could catch fire.
>>
>> Having "released" and "testing" ports trees sound like a good idea.
>
>I disagree. What's the point of putting portfiles in testing?
>Who's going to move them to release when they are ready?
>How installation will pick them?

I agree that the release/testing branches of the ports tree is not a good idea, unless we very explicitely do not index one of the testing branch (you can't pick it up unless you cd to the directory and install--which is how I develop ports out of svn and then move them into svn).

However, versioning the Portfile API is a very good idea, provided that:
1) PortIndex is capable of either
    a) not indexing Portfiles with a PortSystem value that is too high and/or
    b) is capable of storing the PortSystem value in the index.
2) If 1b above, port is capable of ignoring Portfiles with a PortSystem value that exceeds the maximum capable value that port understands.


--
Randall Wood
rhwood at mac.com

"The ball is round. The game lasts ninety minutes. The rest is theory..."



More information about the macports-dev mailing list