Hi, How am I to know if I should be installing a port w/no extra variants used? In particular, I want to install subversion, whose info is: -------- 32 % port info subversion subversion 1.4.2, devel/subversion (Variants: mod_dav_svn, no_neon, no_bdb, mac_os_x_server_mod_dav_svn, tools, darwin_7) http://subversion.tigris.org/ Subversion is a version control system designed to be as similar to cvs(1) as possible, while fixing many outstanding problems with cvs(1). Library Dependencies: expat, neon, apr, apr-util, db44 Maintainers: dluke@geeklair.net ------- I am uncertain how to determine what these things are (e.g. tools). I know I don't want the server, but the others mean nothing to me. Thanks, --b
On Jan 7, 2007, at 3:28 PM, belinda thom wrote:
How am I to know if I should be installing a port w/no extra variants used?
In particular, I want to install subversion, whose info is:
--------
32 % port info subversion subversion 1.4.2, devel/subversion (Variants: mod_dav_svn, no_neon, no_bdb, mac_os_x_server_mod_dav_svn, tools, darwin_7)
Unfortunately there's no simple, standard way to tell what variants one might want for any given port. It would be nice if MacPorts showed more context on a variant, but as far as I can tell, it's up to the given port maintainer. Sometimes when I'm faced with a similar question, I'll look at the actual port file to see if I can ascertain what a variant is doing: cat `port file subversion` I will say that from experience you will probably want +mod_dav_svn, as it provides access to WebDAV-hosted repositories, which includes many public SVN repos. I've tried building Subversion with +no_neon and +no_bdb, but it either caused problems later or didn't make any obvious difference. Here's a link to the Subversion website that should describe what "tools" means: http://subversion.tigris.org/tools_contrib.html --John
On Jan 7, 2007, at 17:28, belinda thom wrote:
How am I to know if I should be installing a port w/no extra variants used?
In particular, I want to install subversion, whose info is:
--------
32 % port info subversion subversion 1.4.2, devel/subversion (Variants: mod_dav_svn, no_neon, no_bdb, mac_os_x_server_mod_dav_svn, tools, darwin_7) http://subversion.tigris.org/
Subversion is a version control system designed to be as similar to cvs(1) as possible, while fixing many outstanding problems with cvs (1).
Library Dependencies: expat, neon, apr, apr-util, db44 Maintainers: dluke@geeklair.net
-------
I am uncertain how to determine what these things are (e.g. tools). I know I don't want the server, but the others mean nothing to me.
+mod_dav_svn builds you the Apache 2 module of that name. If you want to serve a Subversion repository with Apache 2, you need this variant. Since you said you don't want a server, you don't need this. +no_neon builds Subversion without the neon library. Neon is for connecting to http and https Subversion servers. If you want to access repositories served with http or https protocols, do not use the +no_neon variant. +no_bdb builds Subversion without the BerkeleyDB library. BerkeleyDB is one of the two possible ways a repository can be stored on disk, though no longer the default way. Since you said you're not hosting a repository yourself, you don't need BerkeleyDB, so you can use this variant. However, if you really want to avoid having BerkeleyDB on your system (as I do), you will also need to first build the apr-util port with the +no_bdb variant. Otherwise you get an apr-util which will itself pull in BerkeleyDB. +mac_os_x_server_mod_dav_svn I believe builds the Apache 2 module for the Mac OS X Server version of Apache 2, instead of for the MacPorts version of Apache 2 as the +mod_dav_svn variant does. Since you're not planning to run a server, and probably don't have Mac OS X Server, you don't need this variant. +tools installs some additional tools that are provided with the Subversion source code. Specifically, it installs everything listed here into corresponding directories in /opt/local/share/subversion: http://svn.collab.net/repos/svn/trunk/contrib/ http://svn.collab.net/repos/svn/trunk/tools/ For example, I find the svn_load_dirs.pl script helpful. On Jan 7, 2007, at 18:25, John Labovitz wrote:
I will say that from experience you will probably want +mod_dav_svn, as it provides access to WebDAV-hosted repositories, which includes many public SVN repos. I've tried building Subversion with +no_neon and +no_bdb, but it either caused problems later or didn't make any obvious difference.
Actually, mod_dav_svn lets you *serve* repositories over WebDAV. To *access* WebDAV repositories, all you need is neon (that is, you want to *not* specify +no_neon).
Thanks Ryan! On Jan 7, 2007, at 5:48 PM, Ryan Schmidt wrote:
On Jan 7, 2007, at 17:28, belinda thom wrote:
How am I to know if I should be installing a port w/no extra variants used?
In particular, I want to install subversion, whose info is:
--------
32 % port info subversion subversion 1.4.2, devel/subversion (Variants: mod_dav_svn, no_neon, no_bdb, mac_os_x_server_mod_dav_svn, tools, darwin_7) http://subversion.tigris.org/
Subversion is a version control system designed to be as similar to cvs(1) as possible, while fixing many outstanding problems with cvs(1).
Library Dependencies: expat, neon, apr, apr-util, db44 Maintainers: dluke@geeklair.net
-------
I am uncertain how to determine what these things are (e.g. tools). I know I don't want the server, but the others mean nothing to me.
+mod_dav_svn builds you the Apache 2 module of that name. If you want to serve a Subversion repository with Apache 2, you need this variant. Since you said you don't want a server, you don't need this.
+no_neon builds Subversion without the neon library. Neon is for connecting to http and https Subversion servers. If you want to access repositories served with http or https protocols, do not use the +no_neon variant.
+no_bdb builds Subversion without the BerkeleyDB library. BerkeleyDB is one of the two possible ways a repository can be stored on disk, though no longer the default way. Since you said you're not hosting a repository yourself, you don't need BerkeleyDB, so you can use this variant. However, if you really want to avoid having BerkeleyDB on your system (as I do), you will also need to first build the apr-util port with the +no_bdb variant. Otherwise you get an apr-util which will itself pull in BerkeleyDB.
+mac_os_x_server_mod_dav_svn I believe builds the Apache 2 module for the Mac OS X Server version of Apache 2, instead of for the MacPorts version of Apache 2 as the +mod_dav_svn variant does. Since you're not planning to run a server, and probably don't have Mac OS X Server, you don't need this variant.
+tools installs some additional tools that are provided with the Subversion source code. Specifically, it installs everything listed here into corresponding directories in /opt/local/share/subversion:
http://svn.collab.net/repos/svn/trunk/contrib/
http://svn.collab.net/repos/svn/trunk/tools/
For example, I find the svn_load_dirs.pl script helpful.
On Jan 7, 2007, at 18:25, John Labovitz wrote:
I will say that from experience you will probably want +mod_dav_svn, as it provides access to WebDAV-hosted repositories, which includes many public SVN repos. I've tried building Subversion with +no_neon and +no_bdb, but it either caused problems later or didn't make any obvious difference.
Actually, mod_dav_svn lets you *serve* repositories over WebDAV. To *access* WebDAV repositories, all you need is neon (that is, you want to *not* specify +no_neon).
On Jan 7, 2007, at 5:48 PM, Ryan Schmidt wrote:
On Jan 7, 2007, at 18:25, John Labovitz wrote:
I will say that from experience you will probably want +mod_dav_svn, as it provides access to WebDAV-hosted repositories, which includes many public SVN repos. I've tried building Subversion with +no_neon and +no_bdb, but it either caused problems later or didn't make any obvious difference.
Actually, mod_dav_svn lets you *serve* repositories over WebDAV. To *access* WebDAV repositories, all you need is neon (that is, you want to *not* specify +no_neon).
Hm. At one point this was not true. I distinctly remember needing to add some variant in order to get to WebDAV repos. Maybe that has changed. That would be good, as it always seemed like that should be the default. --John
Hi, One final question: how does port handle the case where you've already installed something (e.g. subversion) and you then want to "add on" a variant (e.g. +tools)? Does it do a completely new reinstall, or does it piggy-back off of existing things when it can? Is it standard practice to clean out the existing (via port ... clean) before adding the new variant? Thanks, --b
Unfortunately there's no simple, standard way to tell what variants one might want for any given port. It would be nice if MacPorts showed more context on a variant, but as far as I can tell, it's up to the given port maintainer. Sometimes when I'm faced with a similar question, I'll look at the actual port file to see if I can ascertain what a variant is doing:
cat `port file subversion`
"port cat subversion" might be easier.
On Jan 7, 2007, at 20:36, belinda thom wrote:
One final question: how does port handle the case where you've already installed something (e.g. subversion) and you then want to "add on" a variant (e.g. +tools)? Does it do a completely new reinstall, or does it piggy-back off of existing things when it can? Is it standard practice to clean out the existing (via port ... clean) before adding the new variant?
Well, you can only have a port activated once. If you already have it activated with one set of variants (or with no variants), then you cannot also have it activated with a different set of variants. You can have it *installed* (compiled) with other sets of variants, but only one of the installed combinations can be *active* (used) at a time. For example, if you did this before: sudo port install subversion +no_bdb And now you decide that you also wanted the tools, you could sudo port install subversion +no_bdb +tools After it finishes compiling, it will tell you it cannot activate the new Subversion because another one is already active. You can then uninstall the other Subversion by specifying the complete version and variant string, like this: sudo port uninstall subversion @1.4.2+no_bdb And then activating the new one: sudo port activate subversion Or, instead of uninstalling, you could just deactivate the old one: sudo port deactivate subversion @1.4.2+no_bdb And then activate the new one: sudo port activate subversion @1.4.2+no_bdb+tools (Here you need to specify the full version/variant string to port activate because there's still more than one installed.)
On Jan 7, 2007, at 9:31 PM, John Labovitz wrote:
Actually, mod_dav_svn lets you *serve* repositories over WebDAV. To *access* WebDAV repositories, all you need is neon (that is, you want to *not* specify +no_neon).
Hm. At one point this was not true. I distinctly remember needing to add some variant in order to get to WebDAV repos. Maybe that has changed. That would be good, as it always seemed like that should be the default.
Nope, that has never been true (at least for as long as I've maintained the port). What has been true on a couple of occasions is that either neon or subversion's build system's interaction with neon has been broken (entirely my fault) and so if you built subversion it wouldn't be able to use neon and so you wouldn't be able to access WebDAV repositories (via http or https). -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
Ryan, Thanks for your careful answers. I've learned a lot. Its weird...in the tools there is an .el file (for emacs). But nothing re: pythonbindings is there. I looked at debian's related subversion tools to get a feel for what tools one might expect (the macports src links for tools was great, btw), and there pythonbindings was listed. W/macports, you have to install a separate port (subversion- pythonbindings). In general, I am wondering what rubric macports folks use to decide how to break up functionality... --b p.s. Thanks for your help, I was able to use SVN for the first time ever, downloading a development version of ipython. On Jan 7, 2007, at 8:12 PM, Ryan Schmidt wrote:
On Jan 7, 2007, at 20:36, belinda thom wrote:
One final question: how does port handle the case where you've already installed something (e.g. subversion) and you then want to "add on" a variant (e.g. +tools)? Does it do a completely new reinstall, or does it piggy-back off of existing things when it can? Is it standard practice to clean out the existing (via port ... clean) before adding the new variant?
Well, you can only have a port activated once. If you already have it activated with one set of variants (or with no variants), then you cannot also have it activated with a different set of variants. You can have it *installed* (compiled) with other sets of variants, but only one of the installed combinations can be *active* (used) at a time.
For example, if you did this before:
sudo port install subversion +no_bdb
And now you decide that you also wanted the tools, you could
sudo port install subversion +no_bdb +tools
After it finishes compiling, it will tell you it cannot activate the new Subversion because another one is already active. You can then uninstall the other Subversion by specifying the complete version and variant string, like this:
sudo port uninstall subversion @1.4.2+no_bdb
And then activating the new one:
sudo port activate subversion
Or, instead of uninstalling, you could just deactivate the old one:
sudo port deactivate subversion @1.4.2+no_bdb
And then activate the new one:
sudo port activate subversion @1.4.2+no_bdb+tools
(Here you need to specify the full version/variant string to port activate because there's still more than one installed.)
On Jan 7, 2007, at 9:35 PM, Daniel J. Luke wrote:
On Jan 7, 2007, at 9:31 PM, John Labovitz wrote:
Hm. At one point this was not true. I distinctly remember needing to add some variant in order to get to WebDAV repos. Maybe that has changed. That would be good, as it always seemed like that should be the default.
Nope, that has never been true (at least for as long as I've maintained the port).
What has been true on a couple of occasions is that either neon or subversion's build system's interaction with neon has been broken (entirely my fault) and so if you built subversion it wouldn't be able to use neon and so you wouldn't be able to access WebDAV repositories (via http or https).
Yes, perhaps that was it. I just tested it, and sure enough, a regular "port install subversion" did contain support for WebDAV, and one with the +no_neon lacked that support. To be honest, I never realized that WebDAV access was provided by neon. There was probably a point where I was trying to trim down the requirements to get Subversion installed, and had tried the "+no_neon" variant -- and had then lost the WebDAV access. Or, as you point out, the neon build was broken, and I misdiagnosed the problem. Anyway, my apologies for putting out incorrect information. --John
On Jan 8, 2007, at 12:54 AM, belinda thom wrote:
Thanks for your careful answers. I've learned a lot.
Its weird...in the tools there is an .el file (for emacs). But nothing re: pythonbindings is there. I looked at debian's related subversion tools to get a feel for what tools one might expect (the macports src links for tools was great, btw), and there pythonbindings was listed.
W/macports, you have to install a separate port (subversion- pythonbindings).
In general, I am wondering what rubric macports folks use to decide how to break up functionality...
It's mostly up to the port maintainer. In the case of subversion-pythonbindings (and the other bindings ports) they started out life as port variants (and logically probably belong there, as the bindings-specific ports end up re-compiling a lot of subversion only to delete it and just install the bindings- specific parts). However, MacPorts aren't currently able to depend on other ports' variants, so if you want a port like 'svk' or 'trac' to work (and be able to automatically install its dependencies), the bindings need to be broken out into their own ports. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
Is this really true? I haven't tested, but I was under the impression that when installing something with a variant, any dependencies that are installed at this time also have the same variant applied to them. Meaning, if you don't have apr-util installed, and you install subversion +no_bdb, apr-util should also have +no_bdb applied when it gets automatically installed. On Jan 7, 2007, at 8:48 PM, Ryan Schmidt wrote:
However, if you really want to avoid having BerkeleyDB on your system (as I do), you will also need to first build the apr-util port with the +no_bdb variant. Otherwise you get an apr-util which will itself pull in BerkeleyDB.
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
On Jan 11, 2007, at 5:25 PM, Kevin Ballard wrote:
Is this really true? I haven't tested, but I was under the impression that when installing something with a variant, any dependencies that are installed at this time also have the same variant applied to them. Meaning, if you don't have apr-util installed, and you install subversion +no_bdb, apr-util should also have +no_bdb applied when it gets automatically installed.
That's the way it's supposed to work (and the reason why the variants are named the same). I haven't tried it recently to know if it's broken or not. Ryan may have had apr-util already installed when he needed to rebuild it to get it without bdb. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On Jan 11, 2007, at 16:34, Daniel J. Luke wrote:
On Jan 11, 2007, at 5:25 PM, Kevin Ballard wrote:
Is this really true? I haven't tested, but I was under the impression that when installing something with a variant, any dependencies that are installed at this time also have the same variant applied to them. Meaning, if you don't have apr-util installed, and you install subversion +no_bdb, apr-util should also have +no_bdb applied when it gets automatically installed.
That's the way it's supposed to work (and the reason why the variants are named the same).
Oh really! This is the first time I've heard that.
I haven't tried it recently to know if it's broken or not.
Ryan may have had apr-util already installed when he needed to rebuild it to get it without bdb.
I don't recall. I'll try it again right now. [some time later] Ok, it does build apr-util with +no_bdb also, but it still sees the db44 dependency and downloads db44 and builds it. Which is what I wanted to avoid.
On Jan 11, 2007, at 17:12, Ryan Schmidt wrote:
On Jan 11, 2007, at 16:34, Daniel J. Luke wrote:
On Jan 11, 2007, at 5:25 PM, Kevin Ballard wrote:
Is this really true? I haven't tested, but I was under the impression that when installing something with a variant, any dependencies that are installed at this time also have the same variant applied to them. Meaning, if you don't have apr-util installed, and you install subversion +no_bdb, apr-util should also have +no_bdb applied when it gets automatically installed.
That's the way it's supposed to work (and the reason why the variants are named the same).
Oh really! This is the first time I've heard that.
I haven't tried it recently to know if it's broken or not.
Ryan may have had apr-util already installed when he needed to rebuild it to get it without bdb.
I don't recall. I'll try it again right now.
[some time later]
Ok, it does build apr-util with +no_bdb also, but it still sees the db44 dependency and downloads db44 and builds it. Which is what I wanted to avoid.
And now the log of that: $ sudo port uninstall -f apr Password: ---> Unable to uninstall apr 1.2.8_0, the following ports depend on it: ---> apache2 ---> apache2 ---> subversion ---> apr-util Warning: Uninstall forced. Proceeding despite dependencies. ---> Deactivating apr 1.2.8_0 ---> Uninstalling apr 1.2.8_0 $ sudo port uninstall -f apr-util ---> Unable to uninstall apr-util 1.2.8_1+no_bdb, the following ports depend on it: ---> apache2 ---> apache2 ---> subversion Warning: Uninstall forced. Proceeding despite dependencies. ---> Deactivating apr-util 1.2.8_1+no_bdb ---> Uninstalling apr-util 1.2.8_1+no_bdb $ sudo port uninstall -f subversion ---> Deactivating subversion 1.4.2_0+mod_dav_svn+no_bdb+tools ---> Uninstalling subversion 1.4.2_0+mod_dav_svn+no_bdb+tools $ sudo port install subversion +mod_dav_svn +no_bdb +tools ---> Fetching apr ---> Verifying checksum(s) for apr ---> Extracting apr ---> Configuring apr ---> Building apr with target all ---> Staging apr into destroot ---> Installing apr 1.2.8_0 ---> Activating apr 1.2.8_0 ---> Cleaning apr ---> Fetching db44 ---> Attempting to fetch db-4.4.20.tar.gz from http:// downloads.sleepycat.com/ ---> Verifying checksum(s) for db44 ---> Extracting db44 ---> Configuring db44 ---> Building db44 with target all ---> Staging db44 into destroot ---> Installing db44 4.4.20_0+darwin_8 ---> Activating db44 4.4.20_0+darwin_8 ---> Cleaning db44 ---> Fetching apr-util ---> Verifying checksum(s) for apr-util ---> Extracting apr-util ---> Configuring apr-util ---> Building apr-util with target all ---> Staging apr-util into destroot ---> Installing apr-util 1.2.8_1+no_bdb ---> Activating apr-util 1.2.8_1+no_bdb ---> Cleaning apr-util ---> Fetching subversion ---> Verifying checksum(s) for subversion ---> Extracting subversion ---> Applying patches to subversion ---> Configuring subversion ---> Building subversion with target all ---> Staging subversion into destroot ---> Installing subversion 1.4.2_0+mod_dav_svn+no_bdb+tools ---> Activating subversion 1.4.2_0+mod_dav_svn+no_bdb+tools ---> Cleaning subversion Everything is fine except for all that db44 stuff.
participants (6)
-
belinda thom
-
Daniel J. Luke
-
John Labovitz
-
js
-
Kevin Ballard
-
Ryan Schmidt