Re: Ports and their dependencies
On 6/9/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: All jokes aside, would it be helpful to take the great explanations you have all written and integrating them into chapter 5.4.1 of the MacPorts Guide http://guide.macports.org/#reference.dependencies.types? Is this something that would benefit the MacPorts Community (even though I might have been one of the first people to ask such questions explicitly)? I renamed non-port dependencies to file dependencies. See what you think of the revisions in r37493. It can be refined further if necessary. Thanks to Joshua and Ryan for the explanations. http://trac.macports.org/changeset/37493 Mark, that is great, thank you so much. The term file dependencies makes a ton more sense than non-port. And thanks Josh for proof reading the changes Mark made. This makes the MacPorts community ever more stronger! Tabitha Mark ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies
markd at macports.org wrote: How is it described better in the man page? The man page says what lib,bin,path mean: type:filename:port may be used. Where type is bin if filename is a program, lib if it is a library, or path if it is a path to an installed file. The guide also doesn't explicitly state that the thing at the end of the depspec is a port name (maybe that's obvious though). Another point is that neither the guide nor the man page explicitly states what is done with the port mentioned at the end of non-port depspecs, i.e. it is installed if and only if the specified library, binary or file is not present. Might also want to mention that in lib: dependencies, you list the library name without its extension (e.g. .dylib on Darwin). - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies
On 6/9/08, Joshua Root [EMAIL PROTECTED] wrote: markd at macports.org wrote: How is it described better in the man page? The man page says what lib,bin,path mean: type:filename:port may be used. Where type is bin if filename is a program, lib if it is a library, or path if it is a path to an installed file. Reading this and also the previous posts, the condition of path being a path to an installed file (and given Ryan's example in a different thread whereby the php5 port with the mysql5 variant added triggers the depends_lib of a path whose path value leads to a possibly installed configuration file (but this configuration file only exists if the mysql5_dev port has been installed) kind of strikes me as a means to confusion because such a dependency isn't really a non-port then right? In other words, an installed file which has a path that only exists if the port responsible for installing that file has itself been built and installed, then really that's not a non-port unlike a lib: or bin: which could be, say, an Apple Mac OS X provided resource (library or binary). True? Granted, from a pure syntactical standpoint, the path: ... is not the same as a port: ... and thus I can see why its categorized as a non-port. Thanks, T.M. The guide also doesn't explicitly state that the thing at the end of the depspec is a port name (maybe that's obvious though). Another point is that neither the guide nor the man page explicitly states what is done with the port mentioned at the end of non-port depspecs, i.e. it is installed if and only if the specified library, binary or file is not present. Might also want to mention that in lib: dependencies, you list the library name without its extension (e.g. .dylib on Darwin). - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
On 6/6/08, Ryan Schmidt [EMAIL PROTECTED] wrote: On Jun 6, 2008, at 06:06, Joshua Root wrote: Tabitha McNerney wrote: But, then my script ran into this specific problem: $ port info --depends_lib speex @1.0.5 -- depends_lib: lib:libogg:libogg Ryan, Josh, et al: This may sound like a dumb question, but what would be a suggested way to discover if Apple / Mac OS X is provided the same or similar library for a non-port library dependency of type lib: (e.g. depends_lib: lib:libogg)? In the case of a bin: type I can easily do something like: $ which perl Easy as pie. Is there a command similar to which that can be passed the name of a library from a MacPorts file such as libogg written above? A program such as libtool? Which would come back with info definitively yes or no about the library name collision? I suppose I could also dig for it in /usr/lib but it would be nice to have something like which for libraries as part of my MacPorts quality control script. Thanks, T.M. Hmmm ... the repeat of the library dependency libogg looks to be incorrect. Also, the first instance of the libogg dependency is preceded by lib: but shouldn't that be port: instead? This is not an error, but a different type of dependency. A port:foo dependency means install the port named 'foo', whereas lib:foo:bar means check if the library 'foo' is present, and if not, install the port named 'bar'. You can also use 'bin' or 'path' instead of 'lib' to make the port installation conditional on the absence of executables and arbitrary files, respectively. This is only mentioned in passing in the guide: http://guide.macports.org/#reference.dependencies.types. It's documented a little better in the portfile(7) manual. Most of the time dependencies should be of the port: variety, but sometimes it is better/easier to use software that Apple ships with OS X, a common example being X11. You'll see lib:libX11.6:XFree86 in a lot of portfiles. In the case of the speex port, the dependency should be changed to port:libogg. This port probably dates from a time before MacPorts had port:-style dependencies. I changed the dependency for speex in r37416. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
Tabitha McNerney wrote:
On 6/6/08, *Ryan Schmidt* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On Jun 6, 2008, at 06:06, Joshua Root wrote:
Tabitha McNerney wrote:
But, then my script ran into this specific problem:
$ port info --depends_lib speex @1.0.5
--
depends_lib: lib:libogg:libogg
Ryan, Josh, et al:
This may sound like a dumb question, but what would be a suggested way
to discover if Apple / Mac OS X is provided the same or similar library
for a non-port library dependency of type lib: (e.g. depends_lib:
lib:libogg)? In the case of a bin: type I can easily do something like:
$ which perl
Easy as pie. Is there a command similar to which that can be passed
the name of a library from a MacPorts file such as libogg written
above? A program such as libtool? Which would come back with info
definitively yes or no about the library name collision? I suppose I
could also dig for it in /usr/lib but it would be nice to have something
like which for libraries as part of my MacPorts quality control script.
`locate ${libname}.dylib` would work I guess, though you'd probably want
to filter the output to contain only the paths where MacPorts will
search. Usually that list is as follows:
/Library/Frameworks /Network/Library/Frameworks
/System/Library/Frameworks /lib /usr/lib /usr/X11R6/lib /usr/X11/lib
${prefix}/lib
However, this can be modified by the DYLD_FRAMEWORK_PATH,
DYLD_FALLBACK_FRAMEWORK_PATH, DYLD_LIBRARY_PATH, and
DYLD_FALLBACK_LIBRARY_PATH environment variables.
- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies
On Jun 9, 2008, at 11:17, Tabitha McNerney wrote:
The man page says what lib,bin,path mean:
type:filename:port
may be used. Where type is bin if filename is a
program, lib
if it is a library, or path if it is a path to an
installed file.
Reading this and also the previous posts, the condition of path
being a path to an installed file (and given Ryan's example in a
different thread whereby the php5 port with the mysql5 variant
added triggers the depends_lib of a path whose path value leads to
a possibly installed configuration file (but this configuration
file only exists if the mysql5_dev port has been installed)
I didn't say that: the situation is that either the mysql5 port or
the mysql5-devel port can provide the mysql_config5 file (and indeed
all the MySQL libraries) but only one of these two ports can be
installed at a time. This is (or should be) the case for all -devel
ports. The intention is that most users will use mysql5 but some will
want to try the new features only available in mysql5-devel. To
support this notion, all ports that depend on MySQL 5 functionality
must declare their dependency on MySQL 5 not via a port:-style
dependency (because that would unequivocally require the mysql5 port,
not the mysql5-devel port), but instead via a path:-style dependency
to a specific path within ${prefix}. The lib:-style dependency should
not be used, because a MySQL library provided by the operating system
(for example on Mac OS X Server) would also satisfy that dependency,
but we don't want it to.
Maybe path:${prefix}/something:portname should be the preferred
dependency style (instead of port:portname)? Unless we have a better
plan for -devel ports (or the slots feature) in the future.
kind of strikes me as a means to confusion because such a
dependency isn't really a non-port then right?
I too find the non-port terminology confusing and not entirely
accurate.
In other words, an installed file which has a path that only
exists if the port responsible for installing that file has itself
been built and installed, then really that's not a non-port
unlike a lib: or bin: which could be, say, an Apple Mac OS X
provided resource (library or binary). True? Granted, from a pure
syntactical standpoint, the path: ... is not the same as a
port: ... and thus I can see why its categorized as a non-port.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
On Jun 9, 2008, at 11:23, Tabitha McNerney wrote: This may sound like a dumb question, but what would be a suggested way to discover if Apple / Mac OS X is provided the same or similar library for a non-port library dependency of type lib: (e.g. depends_lib: lib:libogg)? In the case of a bin: type I can easily do something like: $ which perl Easy as pie. Is there a command similar to which that can be passed the name of a library from a MacPorts file such as libogg written above? A program such as libtool? Which would come back with info definitively yes or no about the library name collision? I suppose I could also dig for it in /usr/lib but it would be nice to have something like which for libraries as part of my MacPorts quality control script. Why do you want to know? :-) As a general rule, if you're writing a port that has dependencies on other libraries, declare the dependency on other MacPorts ports. There's no need to investigate which libraries might already be provided with the version of Mac OS X you happen to have on your computer because it might be different in other versions on Mac OS X which is why we try to use only other MacPorts ports so we know what we're getting. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
On Jun 8, 2008, at 06:54, Joshua Root wrote: Depends_lib doesn't apply to only libraries. Its actual meaning is these dependencies are required both at build time and at runtime. Goodness. I never thought of it that way. I suppose I can't find anything wrong with that definition... Depends_build means required at build time but not runtime, and depends_run means required at runtime but not build time. So all dependency specifications (bin,lib,path,port) are valid in each list (depends_lib,depends_build,depends_run). (Do we have preferred disambiguating terminology for these concepts? Would make discussing them a lot clearer...) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
On 6/9/08, Ryan Schmidt [EMAIL PROTECTED] wrote: On Jun 9, 2008, at 11:23, Tabitha McNerney wrote: This may sound like a dumb question, but what would be a suggested way to discover if Apple / Mac OS X is provided the same or similar library for a non-port library dependency of type lib: (e.g. depends_lib: lib:libogg)? In the case of a bin: type I can easily do something like: $ which perl Easy as pie. Is there a command similar to which that can be passed the name of a library from a MacPorts file such as libogg written above? A program such as libtool? Which would come back with info definitively yes or no about the library name collision? I suppose I could also dig for it in /usr/lib but it would be nice to have something like which for libraries as part of my MacPorts quality control script. Why do you want to know? :-) As a general rule, if you're writing a port that has dependencies on other libraries, declare the dependency on other MacPorts ports. There's no need to investigate which libraries might already be provided with the version of Mac OS X you happen to have on your computer because it might be different in other versions on Mac OS X which is why we try to use only other MacPorts ports so we know what we're getting. Ryan, I think I am confused, sorry. The reason I want to know is that I want to be sure that any of the hundreds of ports I install, say on an Xserve, are in fact only dependent on libraries of other MacPorts which libraries would need to be installed. In fact, I don't want any libraries to depend on OS X's names of those same libraries but there might be an exception or two. For example, I do use Apple's X11 application and so let's take the ImageMagik MacPort as an example. ImageMagic has a depend_lib that outputs on the command line (port info --depends_lib ...) with a non-port dependency of type lib: like this: lib:libX11.6:XFree86 How do I (or better yet a script I'm writing) parse that information? Meaning, for example, are libraries associated with libX11.6 supplied by another Mac Port, or does MacPorts look on the root file system (e.g., Mac OS X 10.5 Leopard) to try and find the libraries supplied by Apple (?) with the same namespace associated with libX11.6? Another example, lets' take the sodipodi port. It has a library non-port dependency that looks like this: lib:libgnomeprintui-2-2:libgnomeprintui Can either the libraries associated with libgnomeprintui-2-2 or libgnomeprintui be provided potentially by Mac OS X? Or like the non-port dependency of type path:, only these lib: non-port dependencies can be found within the MacPorts prefix on the filesystem? I just want to be sure that I can know with certainty if any of these libraries might be somehow be provided by OS X and if so when to be alerted when this might be the case ahead of time before I install a port. I hope these questions are clearer, thanks! T.M. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies
All jokes aside, would it be helpful to take the great explanations you have all written and integrating them into chapter 5.4.1 of the MacPorts Guide http://guide.macports.org/#reference.dependencies.types? Is this something that would benefit the MacPorts Community (even though I might have been one of the first people to ask such questions explicitly)? I renamed non-port dependencies to file dependencies. See what you think of the revisions in r37493. It can be refined further if necessary. Thanks to Joshua and Ryan for the explanations. http://trac.macports.org/changeset/37493 Mark ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies
[EMAIL PROTECTED] wrote: All jokes aside, would it be helpful to take the great explanations you have all written and integrating them into chapter 5.4.1 of the MacPorts Guide http://guide.macports.org/#reference.dependencies.types? Is this something that would benefit the MacPorts Community (even though I might have been one of the first people to ask such questions explicitly)? I renamed non-port dependencies to file dependencies. See what you think of the revisions in r37493. It can be refined further if necessary. Thanks to Joshua and Ryan for the explanations. http://trac.macports.org/changeset/37493 Looks good, thanks. I found a couple of bugs though: Line 14/15: though you may remove one with a build dependency should be though you may remove one that is a build dependency. Line 100/101: Note that the replaceablelt;portgt;/replaceable specified is only installed if the file the specified library, binary, or file is not found. Need to remove the file. And one that was incorrect all along: upgrading a port will upgrade its library and build dependencies also, but not its run dependencies. Runtime dependencies are in fact upgraded. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
On Jun 9, 2008, at 19:53, Tabitha McNerney wrote: On 6/9/08, Ryan Schmidt wrote: On Jun 9, 2008, at 11:23, Tabitha McNerney wrote: This may sound like a dumb question, but what would be a suggested way to discover if Apple / Mac OS X is provided the same or similar library for a non-port library dependency of type lib: (e.g. depends_lib: lib:libogg)? In the case of a bin: type I can easily do something like: $ which perl Easy as pie. Is there a command similar to which that can be passed the name of a library from a MacPorts file such as libogg written above? A program such as libtool? Which would come back with info definitively yes or no about the library name collision? I suppose I could also dig for it in /usr/lib but it would be nice to have something like which for libraries as part of my MacPorts quality control script. Why do you want to know? :-) As a general rule, if you're writing a port that has dependencies on other libraries, declare the dependency on other MacPorts ports. There's no need to investigate which libraries might already be provided with the version of Mac OS X you happen to have on your computer because it might be different in other versions on Mac OS X which is why we try to use only other MacPorts ports so we know what we're getting. Ryan, I think I am confused, sorry. The reason I want to know is that I want to be sure that any of the hundreds of ports I install, say on an Xserve, are in fact only dependent on libraries of other MacPorts which libraries would need to be installed. In fact, I don't want any libraries to depend on OS X's names of those same libraries but there might be an exception or two. For example, I do use Apple's X11 application and so let's take the ImageMagik MacPort as an example. ImageMagic has a depend_lib that outputs on the command line (port info --depends_lib ...) with a non-port dependency of type lib: like this: lib:libX11.6:XFree86 How do I (or better yet a script I'm writing) parse that information? Meaning, for example, are libraries associated with libX11.6 supplied by another Mac Port, or does MacPorts look on the root file system (e.g., Mac OS X 10.5 Leopard) to try and find the libraries supplied by Apple (?) with the same namespace associated with libX11.6? X11 is an exception to the usual rule, because the X11 system Apple provides is good and has a Mac OS X look and feel, and XFree86 is large, takes a long time to build, and in the end you get something that looks like Linux, not Mac OS X. Also X11 software seems to be special in that it needs to install into /usr/X11R6 (or /usr/X11 on 10.5 and greater) so you can only install XFree86 if you have not already installed Apple's X11. But Apple's X11 is installed by default on 10.5 and later, and is pretty common on 10.4 too. It's available as a download for 10.3, and isn't available on earlier Mac OS X. For these reasons, for ports that depend on an X Window system, the dependency should be written lib:libX11.6:XFree86 so that they will use the Apple X11 installation if it's installed. If you really do not want to use Apple's X11 to satisfy the X dependency, then uninstall Apple's X11 (remove /usr/X11 (or /usr/X11R6 on 10.4 or earlier) and /Applications/Utilities/X11.app), and then MacPorts will build and use the XFree86 port. Another option is to use the xorg port. xorg is a competing X Window system which should also work. It will also provide libX11.6 so it will also satisfy that dependency. Another example, lets' take the sodipodi port. It has a library non- port dependency that looks like this: lib:libgnomeprintui-2-2:libgnomeprintui Can either the libraries associated with libgnomeprintui-2-2 or libgnomeprintui be provided potentially by Mac OS X? I know of no version of Mac OS X that includes any Gnome components. The sodipodi port has no maintainer, so it has not seen any love in a long time. The dependency on lib:libgnomeprintui-2-2:libgnomeprintui has been in the port since it was originally authored in r4876 on 2004-01-19, likely well before MacPorts had port:-style dependencies. I changed it to a port:-style dependency in r37496. Or like the non-port dependency of type path:, only these lib: non- port dependencies can be found within the MacPorts prefix on the filesystem? All non-port dependencies could be satisfied by things outside of MacPorts, even path:-style depending on how the path is written. For example, mpg123 declares a peculiar dependency on path:/System/ Library/Frameworks/CoreAudio.framework:XXX. I guess it means it requires the CoreAudio framework, and if that's not present, then your Mac OS X is too old? If that case ever occurs, of course, an error will be printed that port XXX could not be found, so this isn't a good way to solve this problem. I just want to be sure
Re: Ports and their dependencies (run deps and also versioning questions)
On 6/6/08, Joshua Root [EMAIL PROTECTED] wrote: Tabitha McNerney wrote: But, then my script ran into this specific problem: $ port info --depends_lib speex @1.0.5 -- depends_lib: lib:libogg:libogg Hmmm ... the repeat of the library dependency libogg looks to be incorrect. Also, the first instance of the libogg dependency is preceded by lib: but shouldn't that be port: instead? This is not an error, but a different type of dependency. A port:foo dependency means install the port named 'foo', whereas lib:foo:bar means check if the library 'foo' is present, and if not, install the port named 'bar'. You can also use 'bin' or 'path' instead of 'lib' to make the port installation conditional on the absence of executables and arbitrary files, respectively. Hi, I have a followup question. I noticed that with the subversion port, when I get information from it (along with enabling its variant, the perl variant), for the lib_depends output, I get: $ port info --depends_lib postgresql81 @8.1.11 +perl -- depends_lib: port:readline, port:openssl, port:zlib, bin:perl:perl5.8 So if I follow Josh's logic, what this means is that there is a library dependency of a non-port type that has an executable condition which is saying, in a paraphrase: the port installation of subversion plus its perl variant has library MacPort dependencies of readline, openssl and zlib' and it has a non-MacPort dependency baed on the perl binary executable. If this perl executable is available on the operating system (e.g., Mac OS X) then use it, but if this perl executable can not be found, then the MacPort perl5.8 should be installed and once its installed its binary executable shall be used ?? Is it not unusual to see binary executable types of non-port dependencies in the library (depends_lib) definition of a port? It doesn't matter if binary requirements are in fact mixed and matched (regardless of dependency type, library, build, run)? Thanks, T.M. This is only mentioned in passing in the guide: http://guide.macports.org/#reference.dependencies.types. It's documented a little better in the portfile(7) manual. Most of the time dependencies should be of the port: variety, but sometimes it is better/easier to use software that Apple ships with OS X, a common example being X11. You'll see lib:libX11.6:XFree86 in a lot of portfiles. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
On Jun 8, 2008, at 05:50, Tabitha McNerney wrote:
Hi, I have a followup question. I noticed that with the subversion
port, when I get information from it (along with enabling its
variant, the perl variant), for the lib_depends output, I get:
$ port info --depends_lib postgresql81 @8.1.11 +perl
--
depends_lib: port:readline, port:openssl, port:zlib, bin:perl:perl5.8
So if I follow Josh's logic, what this means is that there is a
library dependency of a non-port type that has an executable
condition which is saying, in a paraphrase:
the port installation of subversion plus its perl variant has
library MacPort dependencies of readline, openssl and zlib' and it
has a non-MacPort dependency baed on the perl binary executable. If
this perl executable is available on the operating system (e.g.,
Mac OS X) then use it, but if this perl executable can not be
found, then the MacPort perl5.8 should be installed and once its
installed its binary executable shall be used ??
That's about right, except that I would say If the perl executable
is available on the OS, then consider the dependency satisfied,
otherwise install the perl5.8 port.
Is it not unusual to see binary executable types of non-port
dependencies in the library (depends_lib) definition of a port? It
doesn't matter if binary requirements are in fact mixed and matched
(regardless of dependency type, library, build, run)?
Is your question why is a *binary* (executable) appearing in a
*library* dependency clause? That's not necessarily wrong. For
example, in the php5 port's mysql5 variant, I declare the dependency
like this:
depends_lib-append path:${prefix}/bin/mysql_config5:mysql5
The MySQL 5 software doesn't link with the mysql_config5 program as a
library, sure, but it does use the mysql_config5 program at build
time to figure out where the includes and libraries are, and then it
links with those libraries. The point in any of the non-port
dependency declarations is to identify a single representative file,
the presence or absence of which indicates whether the indicated port
needs to be installed to satisfy the dependency or not. In the case
of php5 +mysql5, I declared it this way so that if the user already
has mysql5-devel installed, that will satisfy the dependency. In the
case of postgresql81, the dependency may have been written the way it
was so that if the user already has perl5.10 installed, that would
satisfy the dependency. Actually I think many ports declare their
perl dependency like this so as to avoid forcing the user to install
perl5.8, which is a rather large port, when Mac OS X's included perl
could probably handle the task. For basic perl tasks, perl hasn't
changed in a long time.
I don't know what postgresql81 actually does with perl. If something
installed by the postgresql81 port actually links with one of the
libraries installed by the perl port in ${prefix}/lib/perl5/5.8.8/
darwin-2level/auto then a library dependency (depends_lib) is fine.
But if OTOH something installed by the postgresql81 port merely makes
use of the perl executable at runtime, then a runtime dependency
(depends_run) would be more appropriate. Or, if the perl executable
is just used during the build process to produce something, and then
perl is not needed anymore to run the thing, then a build-time
dependency (depends_build) would be correct (see curl-ca-bundle for
an example). To discover what it should be, we'd have to consult the
PostgreSQL source code or ask the maintainers of the postgresql81
port or the authors of the PostgreSQL software.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
Tabitha McNerney wrote: On 6/6/08, *Joshua Root* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Tabitha McNerney wrote: But, then my script ran into this specific problem: $ port info --depends_lib speex @1.0.5 -- depends_lib: lib:libogg:libogg Hmmm ... the repeat of the library dependency libogg looks to be incorrect. Also, the first instance of the libogg dependency is preceded by lib: but shouldn't that be port: instead? This is not an error, but a different type of dependency. A port:foo dependency means install the port named 'foo', whereas lib:foo:bar means check if the library 'foo' is present, and if not, install the port named 'bar'. You can also use 'bin' or 'path' instead of 'lib' to make the port installation conditional on the absence of executables and arbitrary files, respectively. Hi, I have a followup question. I noticed that with the subversion port, when I get information from it (along with enabling its variant, the perl variant), for the lib_depends output, I get: $ port info --depends_lib postgresql81 @8.1.11 +perl -- depends_lib: port:readline, port:openssl, port:zlib, bin:perl:perl5.8 So if I follow Josh's logic, what this means is that there is a library dependency of a non-port type that has an executable condition which is saying, in a paraphrase: the port installation of subversion plus its perl variant has library MacPort dependencies of readline, openssl and zlib' and it has a non-MacPort dependency baed on the perl binary executable. If this perl executable is available on the operating system (e.g., Mac OS X) then use it, but if this perl executable can not be found, then the MacPort perl5.8 should be installed and once its installed its binary executable shall be used ?? That's right (though the last part, once its installed its binary executable shall be used, is an implicit consequence rather than a guarantee made by the dependency). Is it not unusual to see binary executable types of non-port dependencies in the library (depends_lib) definition of a port? It doesn't matter if binary requirements are in fact mixed and matched (regardless of dependency type, library, build, run)? Depends_lib doesn't apply to only libraries. Its actual meaning is these dependencies are required both at build time and at runtime. Depends_build means required at build time but not runtime, and depends_run means required at runtime but not build time. So all dependency specifications (bin,lib,path,port) are valid in each list (depends_lib,depends_build,depends_run). (Do we have preferred disambiguating terminology for these concepts? Would make discussing them a lot clearer...) As I mentioned in the earlier discussion of gperf, MacPorts didn't always have port: dependencies, so there are probably quite a few of the other kinds left around which should really be changed to port:. Often they don't cause any problems; sometimes, as with gperf, they do. Apart from XFree86, a deliberate one that you'll see a lot is bin:tex:texlive. This is because there are multiple TeX distribution ports, which are quite large, and many ports will work with any of them equally well. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
Ryan and Josh and everyone else, Thank you so very very much for helping to clarify how all this works and disambiguating the terminology and helping to understand how it all lays together logically! We could write a book: The Anatomy of MacPorts and make it a Best Seller on Amazon! All jokes aside, would it be helpful to take the great explanations you have all written and integrating them into chapter 5.4.1 of the MacPorts Guide http://guide.macports.org/#reference.dependencies.types? Is this something that would benefit the MacPorts Community (even though I might have been one of the first people to ask such questions explicitly)? Thanks, T.M. On 6/8/08, Joshua Root [EMAIL PROTECTED] wrote: Tabitha McNerney wrote: On 6/6/08, *Joshua Root* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Tabitha McNerney wrote: But, then my script ran into this specific problem: $ port info --depends_lib speex @1.0.5 -- depends_lib: lib:libogg:libogg Hmmm ... the repeat of the library dependency libogg looks to be incorrect. Also, the first instance of the libogg dependency is preceded by lib: but shouldn't that be port: instead? This is not an error, but a different type of dependency. A port:foo dependency means install the port named 'foo', whereas lib:foo:bar means check if the library 'foo' is present, and if not, install the port named 'bar'. You can also use 'bin' or 'path' instead of 'lib' to make the port installation conditional on the absence of executables and arbitrary files, respectively. Hi, I have a followup question. I noticed that with the subversion port, when I get information from it (along with enabling its variant, the perl variant), for the lib_depends output, I get: $ port info --depends_lib postgresql81 @8.1.11 +perl -- depends_lib: port:readline, port:openssl, port:zlib, bin:perl:perl5.8 So if I follow Josh's logic, what this means is that there is a library dependency of a non-port type that has an executable condition which is saying, in a paraphrase: the port installation of subversion plus its perl variant has library MacPort dependencies of readline, openssl and zlib' and it has a non-MacPort dependency baed on the perl binary executable. If this perl executable is available on the operating system (e.g., Mac OS X) then use it, but if this perl executable can not be found, then the MacPort perl5.8 should be installed and once its installed its binary executable shall be used ?? That's right (though the last part, once its installed its binary executable shall be used, is an implicit consequence rather than a guarantee made by the dependency). Is it not unusual to see binary executable types of non-port dependencies in the library (depends_lib) definition of a port? It doesn't matter if binary requirements are in fact mixed and matched (regardless of dependency type, library, build, run)? Depends_lib doesn't apply to only libraries. Its actual meaning is these dependencies are required both at build time and at runtime. Depends_build means required at build time but not runtime, and depends_run means required at runtime but not build time. So all dependency specifications (bin,lib,path,port) are valid in each list (depends_lib,depends_build,depends_run). (Do we have preferred disambiguating terminology for these concepts? Would make discussing them a lot clearer...) As I mentioned in the earlier discussion of gperf, MacPorts didn't always have port: dependencies, so there are probably quite a few of the other kinds left around which should really be changed to port:. Often they don't cause any problems; sometimes, as with gperf, they do. Apart from XFree86, a deliberate one that you'll see a lot is bin:tex:texlive. This is because there are multiple TeX distribution ports, which are quite large, and many ports will work with any of them equally well. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies
This is not an error, but a different type of dependency. A port:foo
dependency means install the port named 'foo', whereas lib:foo:bar
means
check if the library 'foo' is present, and if not, install the port
named
'bar'. You can also use 'bin' or 'path' instead of 'lib' to make the
port
installation conditional on the absence of executables and arbitrary
files,
respectively.
This is only mentioned in passing in the guide:
[ http://guide.macports.org/#reference.dependencies.types
]http://guide.macports.org/#reference.dependencies.types. It's documented
a little better in the portfile(7) manual.
Most of the time dependencies should be of the port: variety, but
sometimes
it is better/easier to use software that Apple ships with OS X, a common
example being X11. You'll see lib:libX11.6:XFree86 in a lot of
portfiles.
How is it described better in the man page? Below is the text in the
guide. And don't forget that the guide is going to be the source for the
new man pages (1.7? 1.8?), so if the man pages are better in some
respect, the guide needs to be corrected in those respects.
http://guide.macports.org/#reference.dependencies.types
---
Port dependencies should be provided by MacPorts ports whenever possible,
however dependencies may be provided by vendor-supplied software when
satisfying a dependency by a port is not practical or desirable for a
special reason. Dependencies of this type are called non-port dependencies.
Non-port dependencies should only be used if the application or library
can be installed by multiple ports (for example stable and -devel version)
or if it can't be installed with MacPorts.
Port dependencies, the preferred type, are specified as shown in these
examples:
depends_lib port:rrdtool port:apache2
depends_build port:libtool
depends_run port:apache2 port:php5
Non-port dependencies are specified as shown in these examples:
depends_lib lib:libX11.6:xorg
depends_build bin:glibtool:libtool
depends_run path:${prefix}/lib/libltdl.a:libtool
--
Mark
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
Rainer, et al ... On 5/31/08, Rainer Müller [EMAIL PROTECTED] wrote: [snip] Hmm *taking a deep thought* Aaaah, port info! Use like this: $ port info --depends_build --depends_lib --depends_run postfix +ldap You can also add --line to compress the output to one line only. You can hide the label in front of the line and error output by using port -q info. As variants are also parsed from the @version notation, you can simply call this as: $ port -q info --line --depends_build --depends_lib --depends_run \ postfix @2.4.6_0+ldap+pcre+sasl+tls But if you only need the set of variants you have currently installed: $ port -q info --line --depends_build --depends_lib --depends_run \ postfix and installed I have recently written a script that runs the commands as you suggested, for a list of all MacPorts I have on my system. My parsing script pretty much expects this type of format resulting from the port command (example for library dependencies): $ port info --depends_lib portname @version_revision -- depends_lib: [sequence of zero or more: port:dependencyportname] Here's a real example: $ port info --depends_lib libvorbis -- depends_lib: port:libogg In the above example of course we only have one instance of port: which is port:libogg but of course there could be zero or more than one instance. I wrote my script to expect the format of either zero instances or at least one of: depends_lib: port:portname as well has handling the type cases of depends_build: and depends_run: But, then my script ran into this specific problem: $ port info --depends_lib speex @1.0.5 -- depends_lib: lib:libogg:libogg Hmmm ... the repeat of the library dependency libogg looks to be incorrect. Also, the first instance of the libogg dependency is preceded by lib: but shouldn't that be port: instead? Of course the port command is only reading what it sees, which is correct for it do this logically since the port command probably doesn't check for human authoring errors of Portfiles. I state so because I had a look at the speex Portfile and I found this, excerpted: depends_lib lib:libogg:libogg Since my script is going to go through about 450 ports looking for their dependencies (library, build, run), I will find the Portfiles that have errors such as speex above and I imagine the best thing to do is file a ticket / bug reporting true? I will of course also change and correct the errors. Does that seem to be the right thing to do or maybe, if I am missing something, I should instead write my script to adapt for a variety of output conditions such as the above? Thanks, T.M. [snip] ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
Tabitha McNerney wrote: But, then my script ran into this specific problem: $ port info --depends_lib speex @1.0.5 -- depends_lib: lib:libogg:libogg Hmmm ... the repeat of the library dependency libogg looks to be incorrect. Also, the first instance of the libogg dependency is preceded by lib: but shouldn't that be port: instead? This is not an error, but a different type of dependency. A port:foo dependency means install the port named 'foo', whereas lib:foo:bar means check if the library 'foo' is present, and if not, install the port named 'bar'. You can also use 'bin' or 'path' instead of 'lib' to make the port installation conditional on the absence of executables and arbitrary files, respectively. This is only mentioned in passing in the guide: http://guide.macports.org/#reference.dependencies.types. It's documented a little better in the portfile(7) manual. Most of the time dependencies should be of the port: variety, but sometimes it is better/easier to use software that Apple ships with OS X, a common example being X11. You'll see lib:libX11.6:XFree86 in a lot of portfiles. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
On 6/6/08, Joshua Root [EMAIL PROTECTED] wrote: Tabitha McNerney wrote: But, then my script ran into this specific problem: $ port info --depends_lib speex @1.0.5 -- depends_lib: lib:libogg:libogg Hmmm ... the repeat of the library dependency libogg looks to be incorrect. Also, the first instance of the libogg dependency is preceded by lib: but shouldn't that be port: instead? This is not an error, but a different type of dependency. A port:foo dependency means install the port named 'foo', whereas lib:foo:bar means check if the library 'foo' is present, and if not, install the port named 'bar'. You can also use 'bin' or 'path' instead of 'lib' to make the port installation conditional on the absence of executables and arbitrary files, respectively. This is only mentioned in passing in the guide: http://guide.macports.org/#reference.dependencies.types. It's documented a little better in the portfile(7) manual. Most of the time dependencies should be of the port: variety, but sometimes it is better/easier to use software that Apple ships with OS X, a common example being X11. You'll see lib:libX11.6:XFree86 in a lot of portfiles. Thanks Josh, for pointing that sliver of documentation out (I should have found it after Rainer shed light on $ port info ... ). - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
On Jun 6, 2008, at 06:06, Joshua Root wrote: Tabitha McNerney wrote: But, then my script ran into this specific problem: $ port info --depends_lib speex @1.0.5 -- depends_lib: lib:libogg:libogg Hmmm ... the repeat of the library dependency libogg looks to be incorrect. Also, the first instance of the libogg dependency is preceded by lib: but shouldn't that be port: instead? This is not an error, but a different type of dependency. A port:foo dependency means install the port named 'foo', whereas lib:foo:bar means check if the library 'foo' is present, and if not, install the port named 'bar'. You can also use 'bin' or 'path' instead of 'lib' to make the port installation conditional on the absence of executables and arbitrary files, respectively. This is only mentioned in passing in the guide: http://guide.macports.org/#reference.dependencies.types. It's documented a little better in the portfile(7) manual. Most of the time dependencies should be of the port: variety, but sometimes it is better/easier to use software that Apple ships with OS X, a common example being X11. You'll see lib:libX11.6:XFree86 in a lot of portfiles. In the case of the speex port, the dependency should be changed to port:libogg. This port probably dates from a time before MacPorts had port:-style dependencies. I changed the dependency for speex in r37416. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
On Sat, May 31, 2008 at 5:22 PM, Rainer Müller [EMAIL PROTECTED] wrote: Tabitha McNerney wrote: On 5/30/08, Rainer Müller [EMAIL PROTECTED] wrote: $ port deps Xft2 @2.1.12_0 @version is ignored for port deps. port deps takes infos from PortIndex only, so it may not always be accurate. Meaning, if a port has changed (or a new port has been added) but the PortIndex has not been updated? Exactly. Or the port has been installed before, but a new PortIndex (and Portfile) was synced later which adds a new dependency. [...] So this would really be the only way (with a machine and parsing software) to automatically confirm the probable version information of the ldap (openldap port) variant for the library dependency when ldap is a variant tacked on to postfix? Hmm *taking a deep thought* Aaaah, port info! Use like this: $ port info --depends_build --depends_lib --depends_run postfix +ldap You can also add --line to compress the output to one line only. You can hide the label in front of the line and error output by using port -q info. As variants are also parsed from the @version notation, you can simply call this as: $ port -q info --line --depends_build --depends_lib --depends_run \ postfix @2.4.6_0+ldap+pcre+sasl+tls But if you only need the set of variants you have currently installed: $ port -q info --line --depends_build --depends_lib --depends_run \ postfix and installed And if you need this for multiple installed ports, this is also possible. You can use port echo to check to what such a port list expands: $ port echo \( postfix openldap \) and installed or is the default logical operator in such lists, so you do not need to write it explicitely. There is still a little bug though, port -q info --depends_build postfix outputs the usual info as postfix does not have dependencies. I am going to have a look into this. These are awesome features of port, don't you think? I hope you didn't invest too much work into writing your own parser for Portfiles... Rainier, very awesome indeed! Like Ryan, I also was not aware of some of these great features. You really saved the day because I took part of the weekend off and then now (a few days later, thanks for your prompt reply to my email a few days ago) I didn't yet write a Portifle parser so now I'm really glad I don't have to write one -- I can easily use the port command-line output especially with all those goodies (such as the --depends_build, etc.) options! But I have to admit I would have never gotten the idea to use port info if I would not have made other changes to port/port.tcl today. :-) I didn't have a chance yet to look at the changes in Trac but I'll take a look. I'm glad this triggered some additional thoughts and thank you for your modifications! Its great that we can run MacPorts on a variety of machines that can run Mac OS X or OS X Server (whether its a MacBook or an Xserve). The Xserves are pretty heavy-duty systems and and its great to know that we can build a robust infrastructure of open source programs all glued together with MacPorts! All my best, Tabitha Maybe we should really make port deps aware of variants. Rainer ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
Rainer Müller wrote: Maybe we should really make port deps aware of variants. Yes indeed: http://trac.macports.org/ticket/11891 Also related: http://trac.macports.org/ticket/8221 - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
On May 31, 2008, at 22:22, Rainer Müller wrote: So this would really be the only way (with a machine and parsing software) to automatically confirm the probable version information of the ldap (openldap port) variant for the library dependency when ldap is a variant tacked on to postfix? Hmm *taking a deep thought* Aaaah, port info! Use like this: $ port info --depends_build --depends_lib --depends_run postfix +ldap I'm glad to know this! I had no idea. I'll have to incorporate this into my portviz port dependency visualizer to show correct dependencies of installed ports taking into account the selected variants (which it has thus far been unable to do). ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
Rainier and friends ...
On 5/30/08, Rainer Müller [EMAIL PROTECTED] wrote:
[SNIP]
$ port deps Xft2 @2.1.12_0
@version is ignored for port deps.
port deps takes infos from PortIndex only, so it may not always be
accurate.
Meaning, if a port has changed (or a new port has been added) but the
PortIndex has not been updated?
[...]
Is this purely a matter of the active port (Xft2) will only successfully
install (and capable of being activated) based on whatever versions are of
its (library, build, run) dependencies at the moment it is installed?
Dependencies in MacPorts are not on a specific version of a port, just on a
port being installed and active - regardless of variants and version.
Regarding dependencies, I ran into an interesting situation today. I have
the postfix port installed with several variants (such as pcre, tls, sasl
and ldap). However, if one asks for the postfix port's dependencies like
this:
$ port installed postfix
The following ports are currently installed:
postfix @2.4.6_0+ldap+pcre+sasl+tls (active)
then:
$ port deps postfix
yields:
postfix has no dependencies
Oh bummer. I would like to know what the additional dependencies are for the
postfix port with the variants I have for postfix. But since version and
variant are ignored by port deps ... then the only way to retrieve this
information is to parse the following:
1.) the output of $ port installed postfix which as we see above is: postfix
@2.4.6_0+ldap+pcre+sasl+tls (active) ... we can parse the variants by
looking at what comes after the + signs, ok not difficult
2.) parse the postfix Portfile and look up the variant structures, like this
one for ldap:
variant ldap description add ldap support via openldap {
depends_lib-append port:openldap
set CCARGS [concat ${CCARGS} -DHAS_LDAP]
set AUXLIBS [concat ${AUXLIBS} -lldap -llber]
}
Here we can see variant ldap has a depends_lib-append of port:openldap
And then we can check the installed version of openldap:
$ port installed openldap
--
openldap @2.3.35_0 (active)
So this would really be the only way (with a machine and parsing software)
to automatically confirm the probable version information of the ldap
(openldap port) variant for the library dependency when ldap is a variant
tacked on to postfix?
Has anyone else done anything like this? It would be nice to have an
automated system for keeping track of things (like an audit system) since
MacPorts can be complex as it grows.
Thanks,
T.M.
Rainer
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
Tabitha McNerney wrote: On 5/30/08, Rainer Müller [EMAIL PROTECTED] wrote: $ port deps Xft2 @2.1.12_0 @version is ignored for port deps. port deps takes infos from PortIndex only, so it may not always be accurate. Meaning, if a port has changed (or a new port has been added) but the PortIndex has not been updated? Exactly. Or the port has been installed before, but a new PortIndex (and Portfile) was synced later which adds a new dependency. [...] So this would really be the only way (with a machine and parsing software) to automatically confirm the probable version information of the ldap (openldap port) variant for the library dependency when ldap is a variant tacked on to postfix? Hmm *taking a deep thought* Aaaah, port info! Use like this: $ port info --depends_build --depends_lib --depends_run postfix +ldap You can also add --line to compress the output to one line only. You can hide the label in front of the line and error output by using port -q info. As variants are also parsed from the @version notation, you can simply call this as: $ port -q info --line --depends_build --depends_lib --depends_run \ postfix @2.4.6_0+ldap+pcre+sasl+tls But if you only need the set of variants you have currently installed: $ port -q info --line --depends_build --depends_lib --depends_run \ postfix and installed And if you need this for multiple installed ports, this is also possible. You can use port echo to check to what such a port list expands: $ port echo \( postfix openldap \) and installed or is the default logical operator in such lists, so you do not need to write it explicitely. There is still a little bug though, port -q info --depends_build postfix outputs the usual info as postfix does not have dependencies. I am going to have a look into this. These are awesome features of port, don't you think? I hope you didn't invest too much work into writing your own parser for Portfiles... But I have to admit I would have never gotten the idea to use port info if I would not have made other changes to port/port.tcl today. :-) Maybe we should really make port deps aware of variants. Rainer ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Ports and their dependencies (run deps and also versioning questions)
Hello all -- I'm writing a little Ruby script that parses through my list of installed MacPorts. When I find a port that is installed, the script will automatically run the port command to get its dependencies as in: $ port deps Xft2 @2.1.12_0 Xft2 has build dependencies on: pkgconfig Xft2 has library dependencies on: xorg-xproto zlib xrender freetype fontconfig expat The MacPorts documentation says there are three types of dependencies: build, library and run. In the example above of Xft2, we see build and library dependencies listed out on the command line. I have yet to run across a port that also say it has run dependencies. Are there any example of such ports? I just want to make sure that I am parsing the output correctly so a test example would be helpful. Also, on a related note, let's say we run this command, whereby we specify the precise version of Xft2 (2.1.12_0): $ port deps Xft2 @2.1.12_0 (since we might have installed more than one version of the Xft2 port but only one of which is the active port). I observe that, even when specifying the exact version of a port, its dependencies are still dumped out with their general names, rather than both their names and version numbers. Hmmm ... so what if we have two Xft2 version on our system, such as: 2.1.12_0 and 2.2 (I'm making this up for demonstration purposes only) and let's say that the active version of Xft2 is 2.1.12_0. Now, what if Xft2 2.1.12_0 has a library dependency of zlib 1.2.3_1, but Xft2 2.2 has a library dependency of zlib 1.3 (again I'm making this up for demo purposes). Do we have any way of finding out? Even the Portfiles themselves don't specify dependency versions, for example from the Xft2 port file: depends_lib \ port:xorg-xproto \ port:zlib \ port:xrender \ port:freetype \ port:fontconfig \ port:expat Is this purely a matter of the active port (Xft2) will only successfully install (and capable of being activated) based on whatever versions are of its (library, build, run) dependencies at the moment it is installed? Thank you, T.M. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
Hello all (again) -- I just answered one of my questions ... example of a port with runtime dependencies is docbook-xml-4.2 I'd be interested if anyone has any commentary on my other observations. Thanks T.M. On 5/30/08, Tabitha McNerney [EMAIL PROTECTED] wrote: Hello all -- I'm writing a little Ruby script that parses through my list of installed MacPorts. When I find a port that is installed, the script will automatically run the port command to get its dependencies as in: $ port deps Xft2 @2.1.12_0 Xft2 has build dependencies on: pkgconfig Xft2 has library dependencies on: xorg-xproto zlib xrender freetype fontconfig expat The MacPorts documentation says there are three types of dependencies: build, library and run. In the example above of Xft2, we see build and library dependencies listed out on the command line. I have yet to run across a port that also say it has run dependencies. Are there any example of such ports? I just want to make sure that I am parsing the output correctly so a test example would be helpful. Also, on a related note, let's say we run this command, whereby we specify the precise version of Xft2 (2.1.12_0): $ port deps Xft2 @2.1.12_0 (since we might have installed more than one version of the Xft2 port but only one of which is the active port). I observe that, even when specifying the exact version of a port, its dependencies are still dumped out with their general names, rather than both their names and version numbers. Hmmm ... so what if we have two Xft2 version on our system, such as: 2.1.12_0 and 2.2 (I'm making this up for demonstration purposes only) and let's say that the active version of Xft2 is 2.1.12_0. Now, what if Xft2 2.1.12_0 has a library dependency of zlib 1.2.3_1, but Xft2 2.2 has a library dependency of zlib 1.3 (again I'm making this up for demo purposes). Do we have any way of finding out? Even the Portfiles themselves don't specify dependency versions, for example from the Xft2 port file: depends_lib \ port:xorg-xproto \ port:zlib \ port:xrender \ port:freetype \ port:fontconfig \ port:expat Is this purely a matter of the active port (Xft2) will only successfully install (and capable of being activated) based on whatever versions are of its (library, build, run) dependencies at the moment it is installed? Thank you, T.M. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
Tabitha McNerney wrote:
The MacPorts documentation says there are three types of dependencies:
build, library and run. In the example above of Xft2, we see build and
library dependencies listed out on the command line. I have yet to run
across a port that also say it has run dependencies. Are there any
example of such ports? I just want to make sure that I am parsing the
output correctly so a test example would be helpful.
There are lots of them, do some grep:
find $(port dir MacPorts)/../../ -type f -name Portfile \
-exec grep -H depends_run {} \;
Also, on a related note, let's say we run this command, whereby we
specify the precise version of Xft2 (2.1.12_0):
$ port deps Xft2 @2.1.12_0
@version is ignored for port deps.
port deps takes infos from PortIndex only, so it may not always be accurate.
[...]
Is this purely a matter of the active port (Xft2) will only successfully
install (and capable of being activated) based on whatever versions are
of its (library, build, run) dependencies at the moment it is installed?
Dependencies in MacPorts are not on a specific version of a port, just
on a port being installed and active - regardless of variants and version.
Rainer
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Ports and their dependencies (run deps and also versioning questions)
On 5/30/08, Rainer Müller [EMAIL PROTECTED] wrote:
Tabitha McNerney wrote:
The MacPorts documentation says there are three types of dependencies:
build, library and run. In the example above of Xft2, we see build and
library dependencies listed out on the command line. I have yet to run
across a port that also say it has run dependencies. Are there any example
of such ports? I just want to make sure that I am parsing the output
correctly so a test example would be helpful.
There are lots of them, do some grep:
find $(port dir MacPorts)/../../ -type f -name Portfile \
-exec grep -H depends_run {} \;
Also, on a related note, let's say we run this command, whereby we specify
the precise version of Xft2 (2.1.12_0):
$ port deps Xft2 @2.1.12_0
@version is ignored for port deps.
port deps takes infos from PortIndex only, so it may not always be
accurate.
[...]
Is this purely a matter of the active port (Xft2) will only successfully
install (and capable of being activated) based on whatever versions are of
its (library, build, run) dependencies at the moment it is installed?
Dependencies in MacPorts are not on a specific version of a port, just on a
port being installed and active - regardless of variants and version.
Thanks Rainier for this helpful insight!
T.M.
Rainer
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
