new port: grid-packaging-tools

[dennisvd@…]

The ​Globus Toolkit software makes use of GPT (​grid-packaging-tools) for building and packaging. I've created ports for ​many of the Globus Toolkit components, but as a first attempt I submit this one for general review; it has no dependencies outside of what's in macports already.

Description

GPT is a collection of packaging tools built around an XML based packaging data format. This format provides a straight forward way to define complex dependency and compatibility relationships between packages. The tools provide a means for developers to easily define the packaging data and include it as part of their source code distribution. Binary packages can be automatically generated from this data. The packages defined by GPT are compatible with other packages and can be easily converted.

[dennisvd@…]

Cc Me!

[neverpanic (Clemens Lang)]

As the reporter, you don't need to Cc yourself.

[skymoo (Adam Mercer)]

Cc Me!

[lpsinger (Leo Singer)]

Cc Me!

[lpsinger (Leo Singer)]

Why do you have to touch aclocal.m4, Makefile.in, and configure?

[dennisvd@…]

I guess this is meant to force autoconf, aclocal and automake to be run. But now that I think of it: touching Makefile.in and configure makes little sense as these are the products of automake/autoconf and not the sources.

I didn't originally write this code; let me check if it makes a difference if I remove these lines.

[lpsinger (Leo Singer)]

Replying to dennisvd@…:

I guess this is meant to force autoconf, aclocal and automake to be run. But now that I think of it: touching Makefile.in and configure makes little sense as these are the products of automake/autoconf and not the sources.

I didn't originally write this code; let me check if it makes a difference if I remove these lines.

If it does make a difference, a better way to do this is

use_autoreconf      yes

[lpsinger (Leo Singer)]

Why are autoconf, automake, and libtool listed as runtime dependencies? If they are only needed for building, then use_autoreconf yes will add them to depends_build.

[dennisvd@…]

I guess using use_autoreconf yes is generally harmless, and it cleans up the portfile somewhat. But there is more to gpt than meets the eye. The globus toolkit packages depend on it for building and the runtime dependencies may actually be required. I'll have a closer look at it.

[lpsinger (Leo Singer)]

suggested changes for Portfile

[lpsinger (Leo Singer)]

I suggested a few changes by attaching a diff.

• Move perl5 to depends_lib; this way, it is required both to build and to use the port.
• Set distname to gpt-${version. Special settings of checksums and worksrcdir are no longer needed.
• Set use_autoreconf yes and remove pre-configure step.
• Remove Rename libtoolize to glibtoolize stuff in post-destroot. The gpt-bootstrap.sh script can probably be avoided in the other Globus ports by having them set use_autoreconf yes, which does largely the same thing, but more portably.
• Put README files in share/doc/${name} instead of share/doc/${name}-${version}; the former convention appears to be more common in MacPorts.

[dennisvd@…]

Replying to aronnax@…:

I suggested a few changes by attaching a diff.

Thanks! I've included your changes and made a new upload.

• Remove Rename libtoolize to glibtoolize stuff in post-destroot. The gpt-bootstrap.sh script can probably be avoided in the other Globus ports by having them set use_autoreconf yes, which does largely the same thing, but more portably.

Maybe, but a first attempt at building globus-core balked on the autoreconf. The autoheader tool doesn't like one of the AC_DEFINEs in the archaic configure.in. Actually, globus-core comes with a bootstrap script which does slightly more than what autoreconf does, so I think we have to stick to that. It doesn't use gpt-bootstrap.sh, but it calls a few other gpt related scripts.

Anyway, the glibtoolize renaming was wrong anyway. Probably a leftover from earlier days.

[lpsinger (Leo Singer)]

Does it work if you remove --libexecdir='\${datadir}/globus' and --mandir='\${datadir}/man' from the configure args?

[dennisvd@…]

Replying to aronnax@…:

Does it work if you remove --libexecdir='\${datadir}/globus' and --mandir='\${datadir}/man' from the configure args?

Yes, I just checked and the only thing that moves (to /opt/local/libexec) is the gpt-bootstrap.sh script. I'll update the Portfile again.

[lpsinger (Leo Singer)]

You may also want to add openmaintainer; see r105187.

[petrrr]

Cc Me!

[dennisvd@…]

this ticket blocks #39280

[skymoo (Adam Mercer)]

livecheck doesn't work, with the URL scheme not sure how you'd be able to get it working. Maybe disable livecheck?

The home page looks like it hasn't been updated since 2004, is there another homepage that can be used as it doesn't contain information about the version this port provides?

[dennisvd@…]

Replying to ram@…:

livecheck doesn't work, with the URL scheme not sure how you'd be able to get it working. Maybe disable livecheck?

Is this on by default? Normally Globus releases this as part of their Globus Toolkit bundle. So we would have to track Globus Toolkit releases. I'm not sure how to do this. Otherwise, how do I disable livecheck?

The home page looks like it hasn't been updated since 2004, is there another homepage that can be used as it doesn't contain information about the version this port provides?

Evidently, the GPT software has been adopted by Globus and integrated into their Globus Toolkit releases. I think the reference to the original developers is becoming less and less relevant, even if the documentation still points to them and they still have some claim of copyright. But the latest stable release (3.2) of NCSA doesn't look anything like what's currently in Globus Toolkit. So maybe the homepage should be updated.

[skymoo (Adam Mercer)]

Replying to dennisvd@…:

Normally Globus releases this as part of their Globus Toolkit bundle. So we would have to track Globus Toolkit releases. I'm not sure how to do this.

Maybe something like the following:

--- a/devel/grid-packaging-tools/Portfile
+++ b/devel/grid-packaging-tools/Portfile
@@ -8,6 +8,8 @@ PortSystem              1.0

 name                    grid-packaging-tools
 version                 3.6.3
+set globus_version      5.2.4
+set globus_branch       [join [lrange [split ${globus_version} .] 0 1] .]
 revision                1
 platforms               darwin
 categories              devel
@@ -36,7 +38,7 @@ depends_run             port:p5-archive-tar \
                         port:automake \
                         port:libtool

-master_sites            http://www.globus.org/ftppub/gt5/5.2/5.2.4/packages/src/
+master_sites            http://www.globus.org/ftppub/gt5/${globus_branch}/${globus_version}/packages/src/

 distname                gpt-${version}

@@ -58,3 +60,8 @@ post-destroot {
         ${worksrcpath}/LICENSE ${worksrcpath}/README \
         ${destroot}${prefix}/share/doc/${name}
 }
+
+livecheck.type          regex
+livecheck.version       ${globus_version}
+livecheck.url           http://www.globus.org/toolkit/downloads/latest-stable/
+livecheck.regex         {Globus Toolkit (\d+(?:\.\d+)*) Download}

Otherwise, how do I disable livecheck?

livecheck.type          none

Evidently, the GPT software has been adopted by Globus and integrated into their Globus Toolkit releases. I think the reference to the original developers is becoming less and less relevant, even if the documentation still points to them and they still have some claim of copyright. But the latest stable release (3.2) of NCSA doesn't look anything like what's currently in Globus Toolkit. So maybe the homepage should be updated.

Maybe use ​http://www.globus.org/toolkit?

[cooljeanius (Eric Gallager)]

Cc Me!

[skymoo (Adam Mercer)]

One problem with livecheck checking the globus version is that it won't handle the case of advisories, i.e. those from ​http://www.globus.org/toolkit/advisories.html, not sure how that could be handled. But checking the globus toolkit version is better than nothing.

[dennisvd@…]

Replying to ram@…:

One problem with livecheck checking the globus version is that it won't handle the case of advisories, i.e. those from ​http://www.globus.org/toolkit/advisories.html, not sure how that could be handled. But checking the globus toolkit version is better than nothing.

It's a shame livecheck can only inspect a single URL. Otherwise a combination of ​http://www.globus.org/ftppub/gt5/5.2/5.2.4/{packages,updates}/src/ would be perfect.

I think I'll stick to tracking just the bundled Globus Toolkit releases. Thanks!

[dennisvd@…]

updated portfile with livecheck settings

[dennisvd@…]

I've updated the Portfile with the livecheck settings suggested by ram, and removed dependencies on autoconf, automake and libtool which should be automatically included by

use_autoreconf = yes

[skymoo (Adam Mercer)]

Replying to dennisvd@…:

It's a shame livecheck can only inspect a single URL. Otherwise a combination of ​http://www.globus.org/ftppub/gt5/5.2/5.2.4/{packages,updates}/src/ would be perfect.

That would be nice.

[skymoo (Adam Mercer)]

Looks good as far as I'm concerned. Just a quick, is there any reason why you've set revision to one as we start from zero and then increment?

Let's leave it a day or so for other people to weigh in, if we hear nothing I'll get this committed tomorrow.

[dennisvd@…]

Replying to ram@…:

Just a quick, is there any reason why you've set revision to one as we start from zero and then increment?

I'm used to Debian and Fedora builds I guess, they start from 1...

Let's leave it a day or so for other people to weigh in, if we hear nothing I'll get this committed tomorrow.

Great, thanks!

[skymoo (Adam Mercer)]

Replying to dennisvd@…:

I'm used to Debian and Fedora builds I guess, they start from 1...

OK, I'll reset this to zero when I commit.

[skymoo (Adam Mercer)]

r107012