Re: [40328] trunk/dports/textproc/sphinx/Portfile
On Sep 29, 2008, at 11:19 AM, [EMAIL PROTECTED] wrote:
Revision: 40328
http://trac.macports.org/changeset/40328
Author: [EMAIL PROTECTED]
Date: 2008-09-29 09:19:58 -0700 (Mon, 29 Sep 2008)
Log Message:
---
add postgresql83 option for sphinx
Modified Paths:
--
trunk/dports/textproc/sphinx/Portfile
Modified: trunk/dports/textproc/sphinx/Portfile
===
--- trunk/dports/textproc/sphinx/Portfile 2008-09-29 16:19:35 UTC
(rev 40327)
+++ trunk/dports/textproc/sphinx/Portfile 2008-09-29 16:19:58 UTC
(rev 40328)
@@ -20,6 +20,7 @@
distfilessphinx-${version}.tar.gz
checksumssha1 0f82e56a9181b3aeaeef65e9ba82fbf6fbe632d6
+depends_lib-append port:mysql5
configure.args --mandir=${prefix}/share/man \
--datadir=${prefix}/share/doc \
--with-mysql-includes=${prefix}/include/mysql5/mysql \
@@ -27,9 +28,17 @@
test.run yes
-variant postgres description {Enable PostgeSQL support} {
+variant postgres description {Enable PostgreSQL support for old
PgSQL 8.2} {
depends_lib-append port:postgresql82
configure.args-append --with-pgsql
configure.args-append --with-pgsql-includes=${prefix}/
include/postgresql82
configure.args-append --with-pgsql-libs=${prefix}/lib/
postgresql82
}
+
+variant postgresql83 description {Enable PostgreSQL support for
newer PgSQL v8.3} {
+depends_lib-append port:postgresql83
+configure.args-append --with-pgsql
+configure.args-append --with-pgsql-includes=${prefix}/
include/postgresql83
+configure.args-append --with-pgsql-libs=${prefix}/lib/
postgresql83
+configure.args-delete --with-mysql-includes
+}
Is this correct?
You added a global mysql5 dependency which seems to match with the
global --with-mysql-includes configure argument. But in the
postgresql83 variant you delete the configure argument but don't
delete the dependency? And in the postgres variant you don't delete
either of them.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Important: MacPorts PortMgr Changes
Not sure about the name but I love the idea. It'd be great to have a shorter release cycle between 1.x MacPorts releases. Paul. On 30 Sep 2008, at 17:18, James Berry wrote: As many of you know, MacPorts is loosely governed by the PortMgr team, which is currently made up of three people: Markus Weissmann, Juan Manual Palacios, and James Berry. We each love MacPorts, and hope to see it continue to prosper and grow in the future. And we want to continue to contribute to the success of MacPorts as our time and professional lives allow in the future. But we each also have other significant professional and personal commitments that have made it difficult for us to put what we feel is an appropriate amount of time, energy, and enthusiasm into MacPorts in recent months and years, to the extent that we feel that additional day-to-day leadership is needed to ensure continued success and growth for the MacPorts project. So we want to propose some ideas to get new leadership blood into MacPorts, while retaining the systemic knowledge and continuity that our continued presence can allow. We therefore want to put the following plan forward for community comment (and hopefully, thereafter, implementation): (1) That the MacPorts community elect a new slate of PortMgr individuals, probably three people, to continue to guide day-to-day MacPorts operations and direction. (2) That the three of us move into an Elder-council (advisory board, trustees, steering committee, etc), which will continue to help out and give guidance as needed, and watch over the long-term health of MacPorts assets such as domains and finances. The idea for the Elder council is based on our experience in the last several years. We've hesitated to make changes to PortMgr because we didn't want to disrupt continuity, but that has meant that PortMgr has stagnated as year-by-year changes in our lives affected our respective abilities to effectively govern day to day. We (collectively) need the ability to make swifter more responsive changes at the PortMgr level, while also ensuring the longer term continuity of the community and the infrastructure it relies on. We propose that PortMgr members be appointed by the community and have full control of all day-to-day operations of MacPorts. The Elder council will give advice and help to PortMgr members as requested, or as they see fit, but will not have the ability to replace or remove PortMgr members: that responsibility lies with the community. The Elder council might from time to time add or remove its own members: it's primary function is to oversee the long-term health and direction of the project, including long-term assets such as finances and domains. We also see the Elder council as a broader group from which PortMgr can draw for help if its members become temporarily preoccupied with life. We have asked Jordan Hubbard, the father of MacPorts, to join us on the Elder Council, and he has given his tentative acceptance. We'd like to ask for community comment on this plan, following which we hope to call for new PortMgr nominations and election in the coming weeks. We believe that successful nominees for the portmgr positions will have demonstrated an active participation in the MacPorts community, will have the technical and organizational skills to help lead and direct the project, and will have the time, energy, and experience to make and inspire great contributions to the project. The PortMgr team: Markus, Juan, and James ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Important: MacPorts PortMgr Changes
I can't say that I've been a part of this community for very long. However, I think some of my experience speaks to this. First off, Thanks to Markus, Juan and James for the job they've done in getting Macports to where it is now. I was mentally comparing my experience with Macports to the efforts I had to go through when I first started using LinuxPPC. While Macports had the whole MacOS X infrastructure to build off of, it was still much easier to install and use even given that. If the three of you that make up the PortMgr feel that the project is languishing because you can't spend enough time on it, I can't think of anyone more qualified to make that judgement. This seems like a reasonable approach that will allow the community to still have access to your expertise, yet still allow you to focus on the demands in your personal lives. It also allows people to step in to the day-to-day roles that you've been filling. The only addition that I see which could be made to the plan would be to also define how the role of the PortMgr and Elder-councilor gets replaced in the future in the case where people need to move on. Ryan On Sep 30, 2008, at 9:18 AM, James Berry wrote: As many of you know, MacPorts is loosely governed by the PortMgr team, which is currently made up of three people: Markus Weissmann, Juan Manual Palacios, and James Berry. We each love MacPorts, and hope to see it continue to prosper and grow in the future. And we want to continue to contribute to the success of MacPorts as our time and professional lives allow in the future. But we each also have other significant professional and personal commitments that have made it difficult for us to put what we feel is an appropriate amount of time, energy, and enthusiasm into MacPorts in recent months and years, to the extent that we feel that additional day-to-day leadership is needed to ensure continued success and growth for the MacPorts project. So we want to propose some ideas to get new leadership blood into MacPorts, while retaining the systemic knowledge and continuity that our continued presence can allow. We therefore want to put the following plan forward for community comment (and hopefully, thereafter, implementation): (1) That the MacPorts community elect a new slate of PortMgr individuals, probably three people, to continue to guide day-to-day MacPorts operations and direction. (2) That the three of us move into an Elder-council (advisory board, trustees, steering committee, etc), which will continue to help out and give guidance as needed, and watch over the long-term health of MacPorts assets such as domains and finances. The idea for the Elder council is based on our experience in the last several years. We've hesitated to make changes to PortMgr because we didn't want to disrupt continuity, but that has meant that PortMgr has stagnated as year-by-year changes in our lives affected our respective abilities to effectively govern day to day. We (collectively) need the ability to make swifter more responsive changes at the PortMgr level, while also ensuring the longer term continuity of the community and the infrastructure it relies on. We propose that PortMgr members be appointed by the community and have full control of all day-to-day operations of MacPorts. The Elder council will give advice and help to PortMgr members as requested, or as they see fit, but will not have the ability to replace or remove PortMgr members: that responsibility lies with the community. The Elder council might from time to time add or remove its own members: it's primary function is to oversee the long-term health and direction of the project, including long-term assets such as finances and domains. We also see the Elder council as a broader group from which PortMgr can draw for help if its members become temporarily preoccupied with life. We have asked Jordan Hubbard, the father of MacPorts, to join us on the Elder Council, and he has given his tentative acceptance. We'd like to ask for community comment on this plan, following which we hope to call for new PortMgr nominations and election in the coming weeks. We believe that successful nominees for the portmgr positions will have demonstrated an active participation in the MacPorts community, will have the technical and organizational skills to help lead and direct the project, and will have the time, energy, and experience to make and inspire great contributions to the project. The PortMgr team: Markus, Juan, and James ___ macports-users mailing list [EMAIL PROTECTED] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Important: MacPorts PortMgr Changes
On Sep 30, 2008, at 9:18 AM, James Berry wrote: We have asked Jordan Hubbard, the father of MacPorts, to join us on the Elder Council, and he has given his tentative acceptance. First, let me thank James, Markus and Juan for having both the insight and the courage to recognize their own life-induced limitations and put the project ahead of any personal attachments they may feel. That is a less common virtue than one might think, so I raise my hat to them for taking this step and for the degree of thought and care they so clearly put into this message! Second, I do fervently hope that their call for volunteers is not met with the sound of crickets chirping because this project really does need leadership to get to the next phase of its development - milestones like binary packages [available from macports.org], regular builds and associated regression testing, and further improvements to some of the more advanced technologies (at least by comparison to the make-based ports collections we're all familiar with) which underlie MacPorts. There is still a lot of untapped potential in the current design, and the next generation of leadership for MacPorts will have a lot to do with how much energy and focus is applied to these sorts of challenges, so if you're one of the regular faces we see around here (or even someone who's not so regular, but would like to be and sincerely feels they have the time and energy required), please, step up! Finally, I'd like to correct one small misperception, as flattering as it is, which is that I'm the Father of MacPorts. Landon Fuller really deserves that distinction, if any single individual does, and I think it's more accurate to refer to me as the Godfather of MacPorts since I got the project initially created and funded, and you can see my fingerprints here and there in the design (usually as a result of cornering Landon in his office and waving my arms until he gave in on some point), but Landon is the guy who put all the pieces together and actually coded version 1.0. From that point forward, we also owe a debt of gratitude to a number of non-Apple people (and they know who they are) for taking things much, much further and making sure that the baby we left on the community's doorstep did not subsequently die from exposure and neglect [OK, that's a HORRIBLE analogy, but I'm known for those, so I'll just leave it at that]. Thank you portmgr, and thank you macports volunteers! We at Apple will, in turn, continue to contribute where we can by keeping the infrastructure up and running, but it's really up to the community (that's you) at this point, so I really hope people will step into these rather large shoes and make the most of the opportunity to further organize and promote the wealth of open source offerings for Mac OS X! - Jordan ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [PATCH] Inheritance of macports.conf configuration files
Adam, Thanks for the patch. This looks good to me. Does anybody have a use case where inheritance is not the right thing here? James On Sep 30, 2008, at 12:03 PM, Adam Byrtek wrote: There had been no response to my previous post (quoted below), so I decided to try again. Could one of the MacPorts maintainers take a look at the patch, please? This is actually quite a trivial change that will make the user configuration much more convenient. Best regards Adam Byrtek On Fri, Aug 22, 2008 at 10:21 AM, Adam Byrtek [EMAIL PROTECTED] wrote: I've made a tweak in handling of macports.conf configuration file, now the global file defines defaults and user configuration can just override parts of it. More information can be found in this thread on macports-users: http://lists.macosforge.org/pipermail/macports-users/2008-August/011273.html The actual patch is available here: http://trac.macports.org/ticket/16329 A similar problem had been raised on this list a year ago, bus as far as I know didn't result in a patch: http://lists.macosforge.org/pipermail/macports-dev/2007-April/001373.html I'm looking forward for reviewing and applying the patch if you find it valid. Best regards, Adam Byrtek ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [PATCH] Inheritance of macports.conf configuration files
Adam Byrtek wrote: There had been no response to my previous post (quoted below), so I decided to try again. Could one of the MacPorts maintainers take a look at the patch, please? This is actually quite a trivial change that will make the user configuration much more convenient. Sometimes macports-dev is not so responsive and everybody seems busy. Good that you sent out the reminder, I just forgot about this patch already. +1 on applying the patch. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
