Perl 5.8.8 already present on Leopard; can I make a "dummy" Portfile?
Dear all, You'll have to excuse me for my ignorance with regards to Portfiles, since I'm a relative newbe ;) I was playing around with the ghc Portfile in an attempt to update it to the newer ghc version. While playing with this portfile, I noticed that quite a few of the packages I need / use list perl 5.8.8 as a dependency. Macports assumes that the Development Tools are installed. In Leopard, the DT package includes perl 5.8.8 and quite a number of the p5-* packages. The portfile database on macports.org/ports.php lists the perl 5.8.8 package as having no maintainer. Thus, there seems to be no one to do my work for me ;) What I wanted to ask is whether it is possible to create a "dummy" Portfile for Leopard. I tried simply adding the following to the existing perl 5.8.8 Portfile, but ran into (no doubt obvious) trouble: platform darwin 9 { fetch {} checksum {} extract {} patch {} configure {} build {} test {} destroot {} } Is there a cleaner / better way to say "this portfile is installed by default on this platform" or - better still - to check for it and based on that check do or do not do the install? Regards, Philip
On Jan 17, 2008, at 08:08, Philip K.F. Hölzenspies wrote:
You'll have to excuse me for my ignorance with regards to Portfiles, since I'm a relative newbe ;)
Welcome to MacPorts!
I was playing around with the ghc Portfile in an attempt to update it to the newer ghc version. While playing with this portfile, I noticed that quite a few of the packages I need / use list perl 5.8.8 as a dependency. Macports assumes that the Development Tools are installed. In Leopard, the DT package includes perl 5.8.8 and quite a number of the p5-* packages.
The portfile database on macports.org/ports.php lists the perl 5.8.8 package as having no maintainer. Thus, there seems to be no one to do my work for me ;)
What I wanted to ask is whether it is possible to create a "dummy" Portfile for Leopard. I tried simply adding the following to the existing perl 5.8.8 Portfile, but ran into (no doubt obvious) trouble:
platform darwin 9 { fetch {} checksum {} extract {} patch {} configure {} build {} test {} destroot {} }
Is there a cleaner / better way to say "this portfile is installed by default on this platform" or - better still - to check for it and based on that check do or do not do the install?
There are portfiles for many things that are already part of Mac OS X. This is deliberate: http://trac.macosforge.org/projects/macports/wiki/ FAQ#WhyisMacPortsusingitsownlibraries
On Thursday 17 January 2008 16:21:16 Ryan Schmidt wrote:
Welcome to MacPorts!
Thank you ;)
http://trac.macosforge.org/projects/macports/wiki/ FAQ#WhyisMacPortsusingitsownlibraries
I did indeed read this, but my point is slightly more subtle. Allow me to go through the entry in the FAQ in an inline manner: <quote> First, it makes ports more compatible across different versions of Darwin/OS X. If we can rely on e. g. openssl 0.9.8 from MacPorts, we don't have to test every port that needs ssl for every available openssl installation. </quote> My point was actually about a Portfile of a very specific version of perl (5.8.8), which happens to be exactly that version which comes with Leopard. This means that you only assume the default installation and only if explicitly mentioned in the Portfile. Thus, only the Portfile for perl5.8 with version 5.8.8 would have a section for platform darwin 9 that exempts from actually installing it. This is consistent with the observation that MacPorts didn't actually bother installing it's own gcc, but rather simply keep on using the gcc installed with the DT package. <quote> Apple's software tends to break from time to time (e. g. openssl refuses to build with an old zlib, but Apple shipped theold headers of the vulnerable zlib version). </quote> Absolutely true. However, when Apple shifts broken software, it does so with a version of the OS. Tiger contained a funky version of libgmp IIRC, in which case the libgmp Portfile for the version installed on Tiger would NOT exempt from installing when on a darwin 8 platform. <quote> Third reason is up-to-dateness: Apple only features e. g. Python 2.3, not 2.4, with which some software does not work. The drawbacks on this behaviour also are minimal: Wasting 10MB for a Python installation is next to nothing if you have a GB-harddisk and gain consistency all the way in return. </quote> This point still holds. When Portfiles for perl5.8 with version 5.8.9 and 5.8.10 do not have an exemption for darwin 9, they're simply installed. The quote above is slightly optimistic, however, in assuming a general up-to-dateness of MacPorts own portfile tree. This is not true, though. Like I said, ghc required Perl 5.8.8, but the tree contains packages for 5.8.9 and 5.8.10 as well. When another package requires 5.8.9, is perl installed twice? When yet another package wants 5.8.10, is it installed yet another time? If this is not the case, what happens with perl 5.10? Regards, Philip
On Jan 17, 2008, at 09:44, Philip K.F. Hölzenspies wrote:
On Thursday 17 January 2008 16:21:16 Ryan Schmidt wrote:
http://trac.macosforge.org/projects/macports/wiki/ FAQ#WhyisMacPortsusingitsownlibraries
I did indeed read this, but my point is slightly more subtle. Allow me to go through the entry in the FAQ in an inline manner:
<quote> First, it makes ports more compatible across different versions of Darwin/OS X. If we can rely on e. g. openssl 0.9.8 from MacPorts, we don't have to test every port that needs ssl for every available openssl installation. </quote>
My point was actually about a Portfile of a very specific version of perl (5.8.8), which happens to be exactly that version which comes with Leopard. This means that you only assume the default installation and only if explicitly mentioned in the Portfile. Thus, only the Portfile for perl5.8 with version 5.8.8 would have a section for platform darwin 9 that exempts from actually installing it. This is consistent with the observation that MacPorts didn't actually bother installing it's own gcc, but rather simply keep on using the gcc installed with the DT package.
<quote> Apple's software tends to break from time to time (e. g. openssl refuses to build with an old zlib, but Apple shipped theold headers of the vulnerable zlib version). </quote>
Absolutely true. However, when Apple shifts broken software, it does so with a version of the OS. Tiger contained a funky version of libgmp IIRC, in which case the libgmp Portfile for the version installed on Tiger would NOT exempt from installing when on a darwin 8 platform.
Sometimes Apple installs modified versions of software. For example, Apple includes "gcc 4.0.1" with Xcode, but it's a modified version of gcc 4.0.1. I don't know whether Apple's perl 5.8.8 is a modified version or not. Therefore, it's simpler to always install the MacPorts version when perl is required. Also, the rest of the ports that use perl will assume that it and all its parts are somewhere under ${prefix}. If we were to use the system's perl sometimes, this assumption would sometimes not be true. Again, it's simpler to always use MacPorts perl. It would probably be possible to support what you propose, but I feel it would take considerable effort to implement it, and I see no benefit to doing so. Finally, it makes things less predictable. It's much easier to explain that "MacPorts perl always gets used" than it is to explain "MacPorts perl gets used except in these very specific circumstances." Note that some ports do require a more up-to-date gcc, or features which "normal" gcc provides which Apple gcc doesn't, and therefore do depend on, say, the gcc42 port.
<quote> Third reason is up-to-dateness: Apple only features e. g. Python 2.3, not 2.4, with which some software does not work. The drawbacks on this behaviour also are minimal: Wasting 10MB for a Python installation is next to nothing if you have a GB-harddisk and gain consistency all the way in return. </quote>
This point still holds. When Portfiles for perl5.8 with version 5.8.9 and 5.8.10 do not have an exemption for darwin 9, they're simply installed. The quote above is slightly optimistic, however, in assuming a general up-to-dateness of MacPorts own portfile tree. This is not true, though. Like I said, ghc required Perl 5.8.8, but the tree contains packages for 5.8.9 and 5.8.10 as well. When another package requires 5.8.9, is perl installed twice? When yet another package wants 5.8.10, is it installed yet another time? If this is not the case, what happens with perl 5.10?
We have a portfile perl5.8 which installs perl 5.8.8 and a portfile perl5.10 which installs perl 5.10.0. Those are the only two versions of perl that can be installed with MacPorts at this time. If and when perl 5.8.9 or 5.8.10 is released by the perl developers, the perl5.8 port will be updated to that version (and then perl 5.8.8 will no longer be available for installation with MacPorts). MacPorts does not allow you to arbitrarily specify what version of a port to install. You can only install the latest version of a given port. (You can install an older version if you really really want to, but you have to fiddle with it behind MacPorts' back to do so.) Similarly, portfiles cannot depend on a specific version of a given port. They can only depend on a specific port.
On Jan 17, 2008, at 10:44 AM, Philip K.F. Hölzenspies wrote:
My point was actually about a Portfile of a very specific version of perl (5.8.8),
Macports doesn't do fine grained version control (yet?). There is no port for perl that is specifically 5.8.8 (there is a perl5.8 port that currently happens to be version 5.8.8)
Absolutely true. However, when Apple shifts broken software, it does so with a version of the OS. Tiger contained a funky version of libgmp IIRC, in which case the libgmp Portfile for the version installed on Tiger would NOT exempt from installing when on a darwin 8 platform.
Yes, macports could work around every possible broken configuration in order to do what you're requesting, but most maintainers (who are just volunteers) don't have the time to do this. Additionally, when the systems change (and are suddenly broken in new ways in a new version) the macports port won't work under your plan unless/until a maintainer updates them. Under the macports strategy you need to spend a little extra time compiling stuff, and a little extra disk space to hold it, but things are less likely to break unexpectedly. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
participants (3)
-
Daniel J. Luke
-
Philip K.F. Hölzenspies
-
Ryan Schmidt