April 2007 - macports-dev - lists.macosforge.org

Semicolon in long_description, say
by Ryan Schmidt 29 Apr '07

29 Apr '07

I want to use a semicolon in the long_description of a port, minivmac in this case: The default is to emulate a Mac Plus (1986-1990); this is also the best-tested and therefore recommended emulation. If I just include the semicolon by itself, as I would expect to be able to do, portindex blows up. Apparently I have to escape the semicolon in some way. If I precede the semicolon with a backslash, as some ports do (p5- html-strip, xephem, xercesj, monit, abclock, xcircuit, starfighter, ski, galaxis, zile, pccts, nbench-byte), then the word with which the semicolon ends is surrounded with curly braces in the output of port info: The default is to emulate a Mac Plus {(1986-1990);} this is also the best-tested and therefore recommended emulation. If I enclose the entire description string in quotation marks, as some other ports do (xearth, plplot), then the entire description string is surrounded by curly braces in port info: {The default is to emulate a Mac Plus (1986-1990); this is also the best-tested and therefore recommended emulation.} So... what's the solution here to get just a plain semicolon displayed in port info?

1 0

[11796] fixed auctex devel variant
by Dominik Fisch 29 Apr '07

29 Apr '07

Hello, I've opened ticket #11796 to describe the build problem I experienced while trying to build auctex development variant. After playing around a bit I found the problem within the Portfile and submitted a patch. http://trac.macports.org/projects/macports/ticket/11796 Review and commit, anyone? ;-) Bye Dominik

4 4

Re: [24605] trunk/dports/mail/eudora2unix/Portfile
by Ryan Schmidt 29 Apr '07

29 Apr '07

On Apr 28, 2007, at 19:46, source_changes(a)macosforge.org wrote: > Revision: 24605 > http://trac.macosforge.org/projects/macports/changeset/24605 > Author: pguyot(a)kallisys.net > Date: 2007-04-28 17:46:46 -0700 (Sat, 28 Apr 2007) > > Log Message: > ----------- > mail/eudora2unix: Fix platforms declaration. > > Modified Paths: > -------------- > trunk/dports/mail/eudora2unix/Portfile > > Modified: trunk/dports/mail/eudora2unix/Portfile > =================================================================== > --- trunk/dports/mail/eudora2unix/Portfile 2007-04-29 00:42:32 UTC > (rev 24604) > +++ trunk/dports/mail/eudora2unix/Portfile 2007-04-29 00:46:46 UTC > (rev 24605) > @@ -14,8 +14,7 @@ > homepage http://eudora2unix.sourceforge.net/ > master_sites sourceforge > checksums md5 32a4d421510477dfadb2179d29595005 > -# Untested but should probably work on FreeBSD/Linux. > -platform darwin freebsd linux > +platforms darwin > > # Requires Python 2.2.1 or higher. > depends_run bin:python:python24 How should a port developer set the "platforms" declaration? What is its significance? I've generally just been putting "platforms darwin" but I see that not only do we have available platforms like "freebsd" and "linux" but we also have "macosx". What are the guidelines? I forgot to set the "platforms" declaration in the isightcapture port and it still seems to install just fine, so it can't be too essential. Should we just get rid of the "platforms" declaration entirely, especially since we no longer support anything other than Mac OS X?

2 1

Port unarchiving not working
by Blair Zajac 29 Apr '07

29 Apr '07

I'm trying to use the port unarchiving feature but it appears that the unarchive.env is not being honored. Here's the file: $ ls /opt/local/var/db/dports/packages/darwin/i386/commons- pool-1.3_1.i386.tbz2 /opt/local/var/db/dports/packages/darwin/i386/commons- pool-1.3_1.i386.tbz2 $ port -d -v install commons-pool DEBUG: Found port in file:///opt/local/var/db/dports/sources/ rsync.rsync.darwinports.org_dpupdate_dports/java/commons-pool DEBUG: Changing to port directory: /opt/local/var/db/dports/sources/ rsync.rsync.darwinports.org_dpupdate_dports/java/commons-pool DEBUG: Requested variant darwin is not provided by port commons-pool. DEBUG: Requested variant i386 is not provided by port commons-pool. DEBUG: Requested variant macosx is not provided by port commons-pool. DEBUG: Found port in file:///opt/local/var/db/dports/sources/ rsync.rsync.darwinports.org_dpupdate_dports/lang/kaffe DEBUG: Changing to port directory: /opt/local/var/db/dports/sources/ rsync.rsync.darwinports.org_dpupdate_dports/lang/kaffe DEBUG: Searching for dependency: kaffe DEBUG: Didn't find receipt, going to depspec regex for: kaffe DEBUG: Found Dependency: path: /usr/bin filename: java regex: ^java$ DEBUG: Found port in file:///opt/local/var/db/dports/sources/ rsync.rsync.darwinports.org_dpupdate_dports/java/junit DEBUG: Changing to port directory: /opt/local/var/db/dports/sources/ rsync.rsync.darwinports.org_dpupdate_dports/java/junit DEBUG: Searching for dependency: junit DEBUG: Found Dependency: receipt exists for junit DEBUG: Found port in file:///opt/local/var/db/dports/sources/ rsync.rsync.darwinports.org_dpupdate_dports/devel/apache-ant DEBUG: Changing to port directory: /opt/local/var/db/dports/sources/ rsync.rsync.darwinports.org_dpupdate_dports/devel/apache-ant DEBUG: Searching for dependency: apache-ant DEBUG: Found Dependency: receipt exists for apache-ant DEBUG: Executing com.apple.main (commons-pool) DEBUG: Found TBZ2 archive: /opt/local/var/db/dports/packages/darwin/ i386/commons-pool-1.3_1.i386.tbz2 ---> Unpacking tbz2 archive for commons-pool 1.3_1 DEBUG: Executing com.apple.unarchive (commons-pool) DEBUG: Using /usr/bin/tar DEBUG: Using /opt/local/bin/bzip2 ---> Extracting commons-pool-1.3_1.i386.tbz2 DEBUG: Environment: DEBUG: Assembled command: 'cd "/opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_java_commons-pool/work/destroot" && /usr/bin/tar -xvpf -' DEBUG: Executing unarchive_finish Error: Target com.apple.unarchive returned: error copying "/opt/local/ var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_java_commons-pool/work/destroot/+STATE": no such file or directory Warning: the following items did not execute (for commons-pool): com.apple.activate com.apple.unarchive com.apple.fetch com.apple.extract com.apple.checksum com.apple.patch com.apple.configure com.apple.build com.apple.destroot com.apple.archive com.apple.install Error: Status 1 encountered during processing. But the command doesn't contain the "bzip -d -c" I'm not a TCL expert to see why unarchive.env is being set but not ending up in the command. Any ideas? Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair(a)orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/

3 3

Re: Port unarchiving not working
by Blair Zajac 28 Apr '07

28 Apr '07

Hi James, It could be. Should the person who made the changes to the way command.env works modify portunarchive to have it work again? Thanks, Blair On Apr 28, 2007, at 10:58 AM, James Berry wrote: > Hi Blair, > > unarchive.env (or any of the command.env) has to be only > environment settings (FOO=bar FOOD=bad), whatever. This is a recent > change. > > Does that explain the problem you're seeing? > > James > > On Apr 28, 2007, at 10:49 AM, Blair Zajac wrote: > >> I'm trying to use the port unarchiving feature but it appears that >> the unarchive.env is not being honored. >> >> Here's the file: >> >> $ ls /opt/local/var/db/dports/packages/darwin/i386/commons- >> pool-1.3_1.i386.tbz2 >> /opt/local/var/db/dports/packages/darwin/i386/commons- >> pool-1.3_1.i386.tbz2 >> >> $ port -d -v install commons-pool >> DEBUG: Found port in file:///opt/local/var/db/dports/sources/ >> rsync.rsync.darwinports.org_dpupdate_dports/java/commons-pool >> DEBUG: Changing to port directory: /opt/local/var/db/dports/ >> sources/rsync.rsync.darwinports.org_dpupdate_dports/java/commons-pool >> DEBUG: Requested variant darwin is not provided by port commons-pool. >> DEBUG: Requested variant i386 is not provided by port commons-pool. >> DEBUG: Requested variant macosx is not provided by port commons-pool. >> DEBUG: Found port in file:///opt/local/var/db/dports/sources/ >> rsync.rsync.darwinports.org_dpupdate_dports/lang/kaffe >> DEBUG: Changing to port directory: /opt/local/var/db/dports/ >> sources/rsync.rsync.darwinports.org_dpupdate_dports/lang/kaffe >> DEBUG: Searching for dependency: kaffe >> DEBUG: Didn't find receipt, going to depspec regex for: kaffe >> DEBUG: Found Dependency: path: /usr/bin filename: java regex: ^java$ >> DEBUG: Found port in file:///opt/local/var/db/dports/sources/ >> rsync.rsync.darwinports.org_dpupdate_dports/java/junit >> DEBUG: Changing to port directory: /opt/local/var/db/dports/ >> sources/rsync.rsync.darwinports.org_dpupdate_dports/java/junit >> DEBUG: Searching for dependency: junit >> DEBUG: Found Dependency: receipt exists for junit >> DEBUG: Found port in file:///opt/local/var/db/dports/sources/ >> rsync.rsync.darwinports.org_dpupdate_dports/devel/apache-ant >> DEBUG: Changing to port directory: /opt/local/var/db/dports/ >> sources/rsync.rsync.darwinports.org_dpupdate_dports/devel/apache-ant >> DEBUG: Searching for dependency: apache-ant >> DEBUG: Found Dependency: receipt exists for apache-ant >> DEBUG: Executing com.apple.main (commons-pool) >> DEBUG: Found TBZ2 archive: /opt/local/var/db/dports/packages/ >> darwin/i386/commons-pool-1.3_1.i386.tbz2 >> ---> Unpacking tbz2 archive for commons-pool 1.3_1 >> DEBUG: Executing com.apple.unarchive (commons-pool) >> DEBUG: Using /usr/bin/tar >> DEBUG: Using /opt/local/bin/bzip2 >> ---> Extracting commons-pool-1.3_1.i386.tbz2 >> DEBUG: Environment: >> DEBUG: Assembled command: 'cd "/opt/local/var/db/dports/build/ >> _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate >> _dports_java_commons-pool/work/destroot" && /usr/bin/tar -xvpf -' >> DEBUG: Executing unarchive_finish >> Error: Target com.apple.unarchive returned: error copying "/opt/ >> local/var/db/dports/build/ >> _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate >> _dports_java_commons-pool/work/destroot/+STATE": no such file or >> directory >> Warning: the following items did not execute (for commons-pool): >> com.apple.activate com.apple.unarchive com.apple.fetch >> com.apple.extract com.apple.checksum com.apple.patch >> com.apple.configure com.apple.build com.apple.destroot >> com.apple.archive com.apple.install >> Error: Status 1 encountered during processing. >> >> >> But the command doesn't contain the "bzip -d -c" >> >> I'm not a TCL expert to see why unarchive.env is being set but not >> ending up in the command. >> >> Any ideas? >> >> Regards, >> Blair >> >> -- >> Blair Zajac, Ph.D. >> CTO, OrcaWare Technologies >> <blair(a)orcaware.com> >> Subversion training, consulting and support >> http://www.orcaware.com/svn/ >> >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev(a)lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo/macports-dev >

1 0

problems building rpy in linking, appreciate advice?
by John Owens 28 Apr '07

28 Apr '07

Greetings, I'm trying to write a port for rpy, a python set of bindings for R. I'm attaching the build log below. Basically the problem is that it's trying to link to a dynamic library "libRblas.dylib" that is clearly in the right place (/opt/local/lib/R/lib/libRblas.dylib) and whose directory is explicitly specified with -L. (LD_LIBRARY_PATH didn't help either.) Suggestions? This is my first port of this type - it seemed to figure out all sorts of stuff automatically (like to run setup.py). I didn't really have much in the portfile (I'll attach it at the bottom). JDO movenpick 539$ file /opt/local/lib/R/lib/libRblas.dylib /opt/local/lib/R/lib/libRblas.dylib: Mach-O dynamically linked shared library ppc movenpick 540$ sudo port -d install rpy DEBUG: Found port in file:///Users/jowens/Documents/src/dports/python/rpy DEBUG: Changing to port directory: /Users/jowens/Documents/src/dports/ python/rpy DEBUG: Requested variant powerpc is not provided by port rpy. DEBUG: Requested variant darwin is not provided by port rpy. DEBUG: Requested variant macosx is not provided by port rpy. DEBUG: Found port in file:///opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate _dports/lang/python24 DEBUG: Changing to port directory: /opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports /lang/python24 DEBUG: Searching for dependency: python24 DEBUG: Found Dependency: receipt exists for python24 DEBUG: Found port in file:///opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate _dports/math/R DEBUG: Changing to port directory: /opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_ dports/math/R DEBUG: Searching for dependency: R DEBUG: Found Dependency: receipt exists for R DEBUG: Found port in file:///opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_ dpupdate_dports/lang/python24 DEBUG: Searching for dependency: python24 DEBUG: Found Dependency: receipt exists for python24 DEBUG: Skipping completed com.apple.main (rpy) DEBUG: Skipping completed com.apple.fetch (rpy) DEBUG: Skipping completed com.apple.checksum (rpy) DEBUG: Skipping completed com.apple.extract (rpy) DEBUG: Skipping completed com.apple.patch (rpy) DEBUG: Skipping completed com.apple.configure (rpy) ---> Building rpy with target build DEBUG: Executing com.apple.build (rpy) DEBUG: Environment: DEBUG: Assembled command: 'cd "/opt/local/var/db/dports/build/_Users_jowens_Documents_src_dports_python _rpy/work/rpy-1.0-RC2" && /opt/local/bin/python2.4 setup.py build' RHOMES= [] Setting RHOMES to ['/opt/local/lib/R'] ### Using R verion 2.5.0 installed at /opt/local/lib/R ### RHOME= /opt/local/lib/R copying src/rpymodule.c -> src/rpymodule2050.c copying src/R_eval.c -> src/R_eval2050.c copying src/io.c -> src/io2050.c running build running build_py running build_ext building '_rpy2050' extension /usr/bin/gcc-4.0 -bundle -undefined dynamic_lookup build/temp.darwin-8.9.0-Power_Macintosh-2.4/src/rpymodule2050.o build/temp.darwin-8.9.0-Power_Macintosh-2.4/src/R_eval2050.o build/temp.darwin-8.9.0-Power_Macintosh-2.4/src/io2050.o -L/opt/local/lib/R/bin -L/opt/local/lib/R/lib -L/opt/local/lib/R/bin -L/opt/local/lib/R/lib -lR -o build/lib.darwin-8.9.0-Power_Macintosh-2.4/_rpy2050.so /usr/bin/ld: warning can't open dynamic library: libRblas.dylib referenced from: /opt/local/lib/R/lib/libR.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) /usr/bin/ld: Undefined symbols: _dgemm_ referenced from libR expected to be defined in libRblas.dylib _dsyrk_ referenced from libR expected to be defined in libRblas.dylib _zgemm_ referenced from libR expected to be defined in libRblas.dylib _dcopy_ referenced from libR expected to be defined in libRblas.dylib _dtrsm_ referenced from libR expected to be defined in libRblas.dylib _daxpy_ referenced from libR expected to be defined in libRblas.dylib _dswap_ referenced from libR expected to be defined in libRblas.dylib _ddot_ referenced from libR expected to be defined in libRblas.dylib _dasum_ referenced from libR expected to be defined in libRblas.dylib _dscal_ referenced from libR expected to be defined in libRblas.dylib _dnrm2_ referenced from libR expected to be defined in libRblas.dylib _drot_ referenced from libR expected to be defined in libRblas.dylib _drotg_ referenced from libR expected to be defined in libRblas.dylib collect2: ld returned 1 exit status error: command '/usr/bin/gcc-4.0' failed with exit status 1 Error: Target com.apple.build returned: shell command " cd "/opt/local/var/db/dports/build/_Users_jowens_Documents_src_dports_ python_rpy/work/rpy-1.0-RC2" && /opt/local/bin/python2.4 setup.py build " returned error 1 Command output: RHOMES= [] Setting RHOMES to ['/opt/local/lib/R'] ### Using R verion 2.5.0 installed at /opt/local/lib/R ### RHOME= /opt/local/lib/R copying src/rpymodule.c -> src/rpymodule2050.c copying src/R_eval.c -> src/R_eval2050.c copying src/io.c -> src/io2050.c running build running build_py running build_ext building '_rpy2050' extension /usr/bin/gcc-4.0 -bundle -undefined dynamic_lookup build/temp.darwin-8.9.0-Power_Macintosh-2.4/src/rpymodule2050.o build/temp.darwin-8.9.0-Power_Macintosh-2.4/src/R_eval2050.o build/temp.darwin-8.9.0-Power_Macintosh-2.4/src/io2050.o -L/opt/local/lib/R/bin -L/opt/local/lib/R/lib -L/opt/local/lib/R/bin -L/opt/local/lib/R/lib -lR -o build/lib.darwin-8.9.0-Power_Macintosh-2.4/_rpy2050.so /usr/bin/ld: warning can't open dynamic library: libRblas.dylib referenced from: /opt/local/lib/R/lib/libR.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) /usr/bin/ld: Undefined symbols: _dgemm_ referenced from libR expected to be defined in libRblas.dylib _dsyrk_ referenced from libR expected to be defined in libRblas.dylib _zgemm_ referenced from libR expected to be defined in libRblas.dylib _dcopy_ referenced from libR expected to be defined in libRblas.dylib _dtrsm_ referenced from libR expected to be defined in libRblas.dylib _daxpy_ referenced from libR expected to be defined in libRblas.dylib _dswap_ referenced from libR expected to be defined in libRblas.dylib _ddot_ referenced from libR expected to be defined in libRblas.dylib _dasum_ referenced from libR expected to be defined in libRblas.dylib _dscal_ referenced from libR expected to be defined in libRblas.dylib _dnrm2_ referenced from libR expected to be defined in libRblas.dylib _drot_ referenced from libR expected to be defined in libRblas.dylib _drotg_ referenced from libR expected to be defined in libRblas.dylib collect2: ld returned 1 exit status error: command '/usr/bin/gcc-4.0' failed with exit status 1 Warning: the following items did not execute (for rpy): com.apple.activate com.apple.build com.apple.destroot com.apple.install Error: Status 1 encountered during processing. # $Id: Portfile $ PortSystem 1.0 PortGroup python24 1.0 name rpy version 1.0-RC2 revision 1 categories python platforms darwin maintainers nomaintainer(a)macports.org description Python interface to the R Programming Language long_description RPy is a very simple, yet robust, Python interface to the R Programming Language. It can manage all kinds of R objects and can execute arbitrary R functions (including the graphic functions). homepage http://rpy.sourceforge.net master_sites sourceforge:rpy distname rpy-${version} checksums sha1 f3d19253f4f6bd903794b2f9d66ce55a7aa510d1 depends_lib-append port:R port:python24

1 0

Tor and unusual version numbers
by Sbranzo 27 Apr '07

27 Apr '07

Hi, I'm running macports 1.4.3, which seems to be confused by programs with "unusual" versions. For example tor, on my system was version 0.1.1.26, and port outdated never noticed version 0.1.2.13 was available. Bye, Gufo

8 16

options /default
by Yves de Champlain 26 Apr '07

26 Apr '07

Hi I'm working on the gnustep portgroup and have this problem in the portgroup : options gnustep.domain default gnustep.domain "" in a Portfile : build.args DO_LIB_LINK=yes gnustep.domain SYSTEM when running port, the gnustep.domain variable keeps its default value instead of the one provided by the Portfile. build.args is set alright BTW. thanks yves

1 0

Re: Proposal for a new repository layout
by Jordan K. Hubbard 26 Apr '07

26 Apr '07

On Apr 25, 2007, at 12:40 PM, Juan Manuel Palacios wrote: The testing ports tree would just be a facility offered by the project to developers who, like you, develop new features in trunk and/or bug fixes and, naturally, want and need to test them in Portfiles. Such Portfiles break an MP installation based on released code as we've seen one too many times already, so we can't have them in the shipping ("released") ports tree as they are useless there. See, maybe it's just me, but I'd really like to see an end to the distinctions being drawn here concerning "released" vs "testing" since I don't think that's the right place to draw the line. What we're really talking about here, particularly in a possible future where something like James' mpwa (aka "Remote Index") is the way we do things, is "untested" and "vetted". The process of vetting something is still TBD, but one assumes it would involve a lot more testing methodology than we currently have for releases and would actually have some validity. You would also only vet individual portfiles (and, presumably, at least their dependencies), so the process of "releasing" stuff becomes very light-weight and does not require tying everything together in one big bundle just to get some notion of quality control around it. Then we simply have base/, which is periodically tagged to indicate synchronization points for the developer-users of MacPorts (as opposed to core developers, who live on trunk and are the ones who decide when to lay down base tags) and one big pool of Portblobs in the remote database, each blob having the usual range of attributes to facilitate ease of search / categorization as well as the "vetted" and "untested" attributes. If we have all of that, we no longer have to have releases, the whole notion of "a release" becoming essentially meaningless. You just have user selection criteria and a system with enough metadata to make it possible for users to specify whatever criteria makes sense for them. One more point: I still think that people who are actually interested in base/ aren't really "users", they're "user-developers" as I described them earlier. Actual users, which MacPorts has never had at any point in its history, care only about packaged software and a GUI interface for selecting and installing/uninstalling the packages. Those users need plenty of hand-holding and a very abstract view of how to install software. Users who know how to actually install the devtools and compile stuff themselves, even if it's via "port" vs "make", are quite a few steps above actual Users in the food chain and I don't see a lot of benefit (or need) in putting extra effort into coddling them. Just give them the metadata they need to make their own decisions and let them get on with it. - Jordan

1 0

Proposal for a new repository layout
by Juan Manuel Palacios 25 Apr '07

25 Apr '07

Evening everyone! Earlier today I created a branch called "dp2mp- move" where I plan to work on finally moving everything related to the MacPorts project over to the new name (and appropriate equivalents), finally dropping legacy naming and conventions we're still dragging along. For more information on the branch and my goals, you can read the (rather extensive) initial commit log at: http://trac.macports.org/projects/macports/changeset/24454 One of the main goals I'll pursue with this work is designing new distribution means to get both our base sources and ports onto users hands, allowing for enough room to grow in every necessary way and direction. Pivoting on this, I would like to propose a redesign of our existing svn repo layout. Currently we have the following: branches/ (bunch 'o branches here) distfiles/ downloads/ tags/ (bunch 'o tags here) trunk/{base,docs,dports,www} users/ Which is mostly the result of combining our OpenDarwin & cvs inheritance with svn defaults, without much thinking put into it. I believe this layout doesn't suit us well at present for various reasons, which I'll try to explain following. First of all, the trunk & branches & tags default svn hierarchy works in our case only for the base directory, which is the only one we ever branch and/or tag; secondly, having dports inside trunk is misleading at best, mistakenly hinting that our Portfiles can (or even "should") stay in sync with trunk/base when in reality they should be tied to branches/ release_x_y (whatever is currently shipping). These inconsistencies (and the resulting "Portfile works with trunk Vs. Portfile works with release" diatribe) are what's pushing me to relocate both trunk/base and trunk/dports. First and foremost, I propose we make our use of trunk & branches & tags for base only as explicit as it can be, and therefore reorder the existing hierarchy as follows: repository/base/ repository/base/trunk repository/base/branches repository/base/tags Other than base now being a top level dir (emphasized by listing "repository/" in my explanation) and having only MacPorts sources in the directories therein, their usage would still be the self- explanatory svn standard, so nothing would change on that respect. The ports tree would also become a top level dir in our repo, "repository/ports", packing yet another surprise we could leverage as we see fit and need: multiple ports trees! Some examples: repository/ports/released/{categories,...} repository/ports/testing/{categories,...} repository/ports/panther/{categories,...} repository/ports/tiger/{categories,...} repository/ports/leopard/{categories,...} Or whatever else comes to your mind we might need at some point, depending on the project and users needs (agreed that we have platform declarations, so maybe the latter example is not the best one). We would of course have to reach some consensus not only on what trees we carry (we might need per OS trees, we might not), but also on their naming. With this I'm mostly aiming at the following: repository/ports/released/{categories,...} repository/ports/testing/{categories,...} 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. Getting a bit ahead of myself, Portfiles in the testing tree could be free to declare a different PortSystem value, to signal they need a special MacPorts release to function... but said functionality is still not in our code (Eridius? Landon? ;-) Users and committers would be free to suggest the creation of whatever justifiable new tree they find appropriate. Making all of them available through svn and sync (rsync) and whatever else would be immediately beneficial to all, I'm sure it's easy to appreciate. Such rearrangements to our repo would of course require changes in our source code to upgrade existing installations to leverage them (for instance, the selfupdate procedure hardcodes the path to the sources and therefore would break if we change that under the hood c.f. branches/release_1_4 initially missing the base directory level), but I believe the results will be well worth the effort. What I would like to do here is reach consensus on the best possible repo redesign (which I'm hoping does take place!) so that we see ourselves in the need to upgrade users only once. Lastly, the doc and www dirs currently inside trunk could be moved to a "legacy" (detention!) top level dir too (and pulled out of it once brought into the light again ;-) repository/legacy/docs/{www,faq,guide} So, thoughts? Opinions? Ideas? Flames...? Hit your reply-all button in all of those cases ;-) (that is, don't remain quiet! :-P) Regards,... -jmpp PS: Yes, I'm also emphasizing the new ports directory should be called just that, "ports", and not "dports" nor "mports" :-P

4 5