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

Re: [22490] trunk/dports/www/apache2/Portfile
by Randall Wood 04 Mar '07

04 Mar '07

Is this +no_startupitem variant really smart? I recently had a request to add a +without_startupitem variant to a port I maintain and rejected the request; since startupitems simply enable a port to be started at boot time, but do not cause a port to be booted at start time, it simply seems stupid to deliberately cripple a server port such that a user would have to reinstall it if they wanted to start the port at boot time later. BTW: If the variant is to be retained, can it be named +without_startupitem instead? On 2 Mar 2007, at 16:51, source_changes(a)macosforge.org wrote: > Revision 22490 Author blair(a)macports.org Date 2007-03-02 13:51:15 > -0800 (Fri, 02 Mar 2007) Log MessageAdd a +no_startupitem variant > that prevents the automatic startup of the Apache web > server.Modified Paths > trunk/dports/www/apache2/Portfile > Diff > Modified: trunk/dports/www/apache2/Portfile (22489 => 22490)--- > trunk/dports/www/apache2/Portfile 2007-03-02 20:42:45 UTC (rev > 22489) +++ trunk/dports/www/apache2/Portfile 2007-03-02 21:51:15 > UTC (rev 22490) @@ -105,6 +105,10 @@ configure.args-append --with- > mpm=event } +variant no_startupitem { + startupitem.create no +} + > startupitem.create yes startupitem.start \ "\[ -x ${prefix}/apache2/ > bin/apachectl \] && ${prefix}/apache2/bin/apachectl start > /dev/ > null" @@ -112,4 +116,3 @@ "\[ -r ${prefix}/apache2/logs/httpd.pid > \] && ${prefix}/apache2/bin/apachectl stop > /dev/null" > startupitem.restart \ "\[ -r ${prefix}/apache2/logs/httpd.pid \] && > ${prefix}/apache2/bin/apachectl restart > /dev/null" - > _______________________________________________ > macports-changes mailing list > macports-changes(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes Randall Wood rhwood(a)mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

4 5

Re: [22479] trunk/dports/PortIndex
by Salvatore Domenick Desiano 02 Mar '07

02 Mar '07

WOW. So, that 4.1MB e-mail never needs to happen again. Can we put a filter on the outgoing SVN e-mails? -- Sal smile. -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University

3 2

Spring-cleaning @opendarwin.org addresses
by Elias Pipping 02 Mar '07

02 Mar '07

Carried out. see * mail: http://www.mail-archive.com/macports- dev(a)lists.macosforge.org/msg00309.html * ticket: http://trac.macosforge.org/projects/macports/ticket/11465 * changeset: http://trac.macosforge.org/projects/macports/changeset/ 22478 Regards, Elias Pipping

2 1

MacPorts and Summer of Code - first steps
by Jordan K. Hubbard 02 Mar '07

02 Mar '07

First, I think this is a great idea and thanks go to whomever suggested it - MacPorts is full of the sorts of projects that summer- of-coders could do in the time allotted. Second, before google is even approached I think the project needs to pull a wish-list together and demonstrate that it's not just looking for some free labor to get a bit of grunt work done, it's got some project ideas that will really move the project forward and demonstrably improve its utility to the Macintosh community at large. I've been one of the google SoC mentors (for FreeBSD) and I can say that the project ideas which tend to get funding aren't the ones which go "clean up our man pages and look for typos", they're more along the lines of "port ZFS to FreeBSD". Furthermore, I *know* that MacPorts has a number of long-stalled efforts in base/ which are just waiting for someone to go dive on them single-mindedly. Just thinking right off the top of my head, some of these are: 1. Finish the work Paul Guyot started with the trace code and create real "virtual chroot" environments for building ports, constraining what their configure scripts can see and validating that their explicit dependencies are correct and fully-formed. 2. Working in concert (or cooperatively) with whomever does #1, get package building working all the way to a point where complete package builds can be done for all of MacPorts and the results made available to users as pre-build package collections. 3. Come up with a front-end for installing packages (or building ports, where no package exists) for naive end-users. 4. Take what Will started with the notion of a depot location vs an installed location (e.g. /opt/local/var/db/dports/software/gawk/ 3.1.5_2/opt/local/bin/gawk vs /opt/local/bin/gawk) and finish the job, making depot-to-depot dependencies finally work. That is to say that if port foo depends on version 1.2.3 of port bar, it should be compiled and linked in such a way that it's wired to the depot location of bar, not the "activated" location. That will finally fix the fragility problem where deactivating port bar vers n-1 in order to install port bar vers n (because other things depend on n) won't also require breaking everything that relies on n-1. 5. Sweep through all Portfiles and look for useful opportunities to add more built-in Tcl functions that make Portfiles more (usefully) terse, powerful, flexible or easier to write. I'm sure there is an entirely family of helper functions yet to be written here. That's just 5 off the top of my head with about the same number of minutes work devoted to pulling them out of my memory. I know that I've seen easily 10 times that many "good idea, someone should do that!" emails fly by the lists over the last few years too, so I'm sure others can easily add to this list. Approaching google is also something that shouldn't be done ad-hoc by a number of people all claiming to represent macports in some way. Someone wearing the portmgr mantle needs to collect all these ideas, get some democratic input as to which ideas are truly the best, then approach google with the list and try to get added as a SoC project. They need to do it quickly too since we don't have much time. I nominate jmpp. - Jordan

2 1

textproc/xercesc doesn't build
by Anant Narayanan 02 Mar '07

02 Mar '07

Hi all, The textproc/xercesc port didn't build. I've attached a patch to the ticket (#11463) to correct the MD5 and ${worksrcdir}. http://trac.macports.org/projects/macports/ticket/11463 Cheers, -- Anant

2 2

MacPorts: extracting to multiple locations
by John Ridgway 01 Mar '07

01 Mar '07

Friends - I'm working on a cleanup of the xemacs PortFile - splitting it into xemacs and xemacs-beta, and ensuring that without the sumo option you still get the base packages. In doing this I'm discovering that I need to extract different distribution files into different places in the build tree. Is there a standard way to do this, or can somebody point me to another port that does something similar? Peace - John

2 1

Emacs major modes
by Yuen Ho Wong 01 Mar '07

01 Mar '07

Hi Macport Devs, Just out of curiosity, how come there is such a lack of ported emacs modes? Are there any plans to incorporate more emacs mode in Macports or do I have to roll my own? Yuen Ho Wong

2 1

Python 2.5 and py-crypto...
by Douglas Philips 01 Mar '07

01 Mar '07

Sorry for not having been paying close attention, but I found I needed python 2.5, so I installed that. I also needed py-crypto, but that has a dependency on python24 and no py25-crypto package was available. So, I fetch'd and extract'd plain ol py-crypto, then with python 2.5 on my PATH I was able to build, test, and install it (into /opt/local/ lib/python2.5/...) and so far it seems to be working fine. --Doug

8 11