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

Re: Draft of a minimalist MacPorts Guide
by Juan Manuel Palacios 06 Jul '07

06 Jul '07

Hi Mark! I've only managed to skim over your draft but I think it seems pretty good to begin with, kudos! Even though the existing guide is pretty outdated in some aspects, I wouldn't know where to stand between this draft of yours and our existing sources (there is some good material there!), haven't really had the time to do any serious comparisons. I'd love it if you could team up with Maun Suang and Brian Campbell, who've been actively contributing to documentation lately, and come up with a plan to rewrite as much as you can while keeping the best of both. Doing it in docbook format would be sweet, we already have automated guide regen straight off svn sources going on Daniel Luke's box, meaning that whatever we commit to the doc/ svn dir is reflected on the regen'd html files automagically, no fuss! (what's the regen periodicity, Daniel?). We also have a temporary location for the guide up at Daniel's site (http://geeklair.net/macports_guide/) but I am coordinating with Kevin Van Vechten a move to MacOSForge servers with a static link to it and automated uploads, this time for real. We're are also working on a mechanism to grant wiki write access to documentation contributors who do not yet have full svn write access, so that we can broaden our contributors base in a much faster and way. I'll get back to everybody once all this is in place, though. So as you can see, we already have this ball rolling with revived energies, so I'd really love it if you could team up and work people like Maun Suang and Brian (and any other willing to dedicate some time to this, most welcome!), providing your new draft as a base for a major guide redesign and refresh. Again, kudos for this great effort! Regards,... -jmpp On Jul 5, 2007, at 4:10 PM, markd(a)macports.org wrote: > I think the structure of the original guide is fundamentally > flawed. I > cooked up a draft of a minimalist approach. What do y'all think? > > http://homepage.mac.com/duling/macports/guide.html > > I used the stylesheet from another document I had handy, so don't > mind the > format or the fact that it isn't chunked. The colors and text of the > original guide make it look more professional I think but I didn't > have > time to mess with the stylesheet, especially since I don't know if > people > will really like this approach anyway. > > Mark > > _______________________________________________ > macports-users mailing list > macports-users(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-users

2 1

Re: RPM/SRPM target change for 1.5
by Juan Manuel Palacios 06 Jul '07

06 Jul '07

On Jul 5, 2007, at 11:38 AM, Anders F Björklund wrote: > FYI, > These packaging changes should go in MacPorts 1.5 as well...: > http://trac.macosforge.org/projects/macports/changeset/26730 > http://trac.macosforge.org/projects/macports/changeset/26731 These two have been merged. > Will commit another change to those two, to make it word wrap. That's changeset r26737, I need to know whether you want it merged into 1.5 or not. While on it, I would really like to encourage you to please create a base/src/package1.0/package_util.tcl TCL package into which we can factor out common code shared between all the packaging targets, properly abstracted if need be. It may sound like a bit of an undertaking, but maybe we can start low and slow with the word wrap proc that you had to duplicate between the rpm and srpm targets...? > > --anders > Regards,... -jmpp

2 1

deploying pre-build ports with macports
by Barry Wark 05 Jul '07

05 Jul '07

I'm planning a deployment of scientific software to several users in my lab. The software depends on several libraries that aren't installed by default on OS X. We've settled on macports for providing those dependencies (and have been very impressed with the whole project- kudos!). I would like to deploy our whole package, including macports, as a single installer. Here was my plan. I'd appreciate feedback from any of the devs about whether this will work: As part of the metapackage for deploying our entire software suite, I plan to include the stock macports installer (to add the appropriate receipt to /Library/Receipts), followed by an installer that overwrites the /opt/local tree with the /opt/local tree from our development machine that has all of the dependencies built and activated (all machines are the same OS version and architecture). Will this work or will I hose the macports installation on the target machines? Thanks, Barry

2 1

Re: [26727] trunk/dports/python
by Juan Manuel Palacios 05 Jul '07

05 Jul '07

On Jul 5, 2007, at 2:30 PM, Anders F Björklund wrote: > >>> +depends_lib-append port:py-celementtree >> >> Why use an append construct if we're not modifying any >> already defined depends array? We should always use 'depends_lib >> <deps>' to first define the array and only then modify it with '- >> {append,delete}' if need be (variants, most likely), regardless of >> whether or not your construct above works to begin with (I think >> it does after Kevin fixed a related bug a while ago, but still....). > > I was under the impression that the PortGroup defined depends_lib, > but I will be happy to change the port above. > > --anders > Then please do completely ignore me and let me crawl back into my cave if that's the case (didn't even notice you were calling a PortGroup!). Let me run now ;-) -jmpp

1 0

Re: [26694] trunk/base/ChangeLog
by markd＠macports.org 05 Jul '07

05 Jul '07

macports-dev(a)lists.macosforge.org on Tuesday, July 3, 2007 at 11:17 PM -0800 wrote: >+ - Added new variable ${os.major} that contains the Tcl major version >(eridius r26693, ticket #12224). Kevin, Can you please explain the naming of this variable? If it represents the major Tcl version, shouldn't it be named accordingly? Doesn't os.major imply that it represents the major version of the OS? Mark

2 1

Platform versions and Binaries
by Anders F Björklund 04 Jul '07

04 Jul '07

There is a upcoming problem that will occur with the binary archives/packages, in that most of the code currently only checks for ${os.platform} and ${os.arch} when looking for binaries, ignoring ${os.version} which might be important ? e.g. Panther and Tiger will try to use the same binaries and archives, and ditto for FreeBSD STABLE and CURRENT... So we might need to include at least the major version in the paths used, so that they will become something like: darwin/9/i386/ darwin/9/ppc/ darwin/8/i386/ darwin/8/ppc/ darwin/7/ppc/ freebsd/7/i386/ freebsd/6/i386/ freebsd/5/i386/ ... This goes for /opt/local/var/macports/packages, and for remote fetching. It also goes for all RPM repositories. Universal packages should probably go in a special place too, since they use the 10.4.u SDK and the "fat" arch ? Eventually one _might_ want to share "noarch"* packages between architectures, and maybe even between platforms. --anders * http://trac.macports.org/projects/macports/ticket/12206

2 3

Problem with configure.env and build.env
by Simon Ruderich 04 Jul '07

04 Jul '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I'm trying to build qt3-mac but it failed with the same error like reported on [trac][]. After doing some debugging I found the problem. The environment specified in build.env is not set and so the libraries are not found because DYLD_LIBRARY_PATH is not set correctly. I don't know why the environment is not setup correctly, but it looks like it's not working for configure.env either. The output with port -d shows the build environment is empty and the configuration environment is only filled with default values and not those from the Portfile. - ---> Configuring qt3-mac DEBUG: Executing com.apple.configure (qt3-mac) DEBUG: Environment: CXXFLAGS='-O2' CPPFLAGS='-I/opt/local/include' CFLAGS='-O2' LDFLAGS='-L/opt/local/lib' DEBUG: Assembled command: ... ... - ---> Building qt3-mac with target symlinks src-qmake src-moc sub-src sub-tools DEBUG: Executing com.apple.build (qt3-mac) DEBUG: Environment: DEBUG: Assembled command: ... I fixed this problem temporarily by added the following line to the build rules in the Portfile. build.cmd "export DYLD_LIBRARY_PATH='${worksrcpath}/lib'; make" But this is of course no real solution, but so I could build qt3-mac. If you please could look into this. I'm using port version 1.442 (fresh 4.000 install and updated using port selfsync). Thanks for your help, Simon [trac]: http://trac.macports.org/projects/macports/ticket/11895 - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGi+WsYRX4BO+zMikRCn0ZAKDXl7W+XJVBW/ZQ3Q616XdGhuqTAACgof51 dU4JK3EfV/TMeJa2TD6ntxQ= =LnEK -----END PGP SIGNATURE-----

2 1

symbolic link traversal
by Boyd Waters 02 Jul '07

02 Jul '07

Howdy all! When you get finished playing with your shiny new iPhone, I have a maybe-stupid question about symbolic links: 1) Does MacPorts traverse symlinks in the middle of a path/like/this (where "like" would be a symlink) I found a likely bit of Tcl code, and attempted to set it up to recursively resolve symlinks correctly during path traversal, but was not able to fix the problem. I've been holding off on committing my Python ports -- which permit multiple, parallel versions of MacPorts to co-exist on a system -- but I would rather get this path-traversal thing addressed and then clean up the work-arounds in my ports. A related issue: the binary PKG files that are produced by MacPorts are very dangerous for a similar reason: they don't resolve intermediate symlinks, either. Instead, the installer with *wipe out* the intermediate symlink, replacing it with a "real directory" -- which of course only contains the stuff in that particular package. For example, /etc -- which is a symlink to /private/etc -- is *deleted* and *replaced* by an /etc that only contains an X11 subdir by the emacs binary pkg installer. Ouch! 2) I will try to clean up pkg-creation, unless someone else wants to hit it. Who maintains the PKG binary-installer part of MacPorts? Thanks! - boyd Boyd Waters National Radio Astronomy Observatory middle of nowhere New Mexico USA

1 0

Re: [26541] trunk/doc/guide/xml/portfiles/details.xml
by Juan Manuel Palacios 01 Jul '07

01 Jul '07

Hi Maun Suang! Well, first of all, on behalf of the entire team thanks again for all this love you're devoting to the until now much abandoned guide, I'm sure a large user base will be very pleased to see this work come to fruition! About one of the changes you made here: > - configuration file /etc/ports/ports.conf. Can be > + configuration file ${prefix}/etc/ports/macports.conf. Can be I plan to release MacPorts 1.5 soon now (I've been preparing base for the last days and think it's time to branch already), so I'd love it if we could detail all throughout the entire guide the new installation layout resulting from the work I did on the dp2mp-move branch. You can read about it here: http://trac.macports.org/projects/macports/wiki/MacPortsRenaming And as that's what we'll be handing off to users in the near future we should start documenting it and adapting old documentation to it. I'll correct this one below in a sec... but just for future reference ;-) Regards,,... -jmpp On Jun 28, 2007, at 1:25 AM, source_changes(a)macosforge.org wrote: > Revision > 26541 > Author > boeyms(a)macports.org > Date > 2007-06-27 22:25:27 -0700 (Wed, 27 Jun 2007) > Log Message > > doc/guide/xml/portfiles: > * Correct names of some paths that MacPorts uses. > Modified Paths > > trunk/doc/guide/xml/portfiles/details.xml > Diff > > Modified: trunk/doc/guide/xml/portfiles/details.xml (26540 => 26541) > --- trunk/doc/guide/xml/portfiles/details.xml 2007-06-28 05:23:48 > UTC (rev 26540) > +++ trunk/doc/guide/xml/portfiles/details.xml 2007-06-28 05:25:27 > UTC (rev 26541) > @@ -71,10 +71,10 @@ > <term>prefix</term> > <listitem> > <para>Installation prefix, set in the systemwide > - configuration file /etc/ports/ports.conf. Can be > + configuration file ${prefix}/etc/ports/macports.conf. Can be > overridden on a per port basis. For example XFree86 > needs to install in the /usr tree, or aqua applications > - are installed in /Applications/Ports</para> > + are installed in /Applications/MacPorts</para> > > </listitem> > </varlistentry> > _______________________________________________ > macports-changes mailing list > macports-changes(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes

2 4