[Bug 453847] Review Request: gpt - The Grid Packaging Toolkit

Wed Jul 16 07:37:37 UTC 2008

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: gpt - The Grid Packaging Toolkit

https://bugzilla.redhat.com/show_bug.cgi?id=453847

------- Additional Comments From mattias.ellert at fysast.uu.se  2008-07-16 03:37 EST -------
Sorry for the delay of this iteration. Globus made a new release of the globus
toolkit, so I had to update my packages accordingly.

After communicating with the upstream GPT, I have been informed that the
maintenance of GPT has been transferred from NCSA to the Globus Alliance, so I
have based the new GPT SRPM on the latest tarfile from globus.org. (This
transfer is not indicated anywhere on the www.gridpackagingtools.org website
though.)

(In reply to comment #7)

> In fact the renaming of the package cannot be done only in fedora,
> the naming guidelines mandate that the package is called gpt in
> that case.

So the name is back to gpt, new version is here:

SRPM:
http://www.grid.tsl.uu.se/repos/globus/fedora/9/src/SRPMS/gpt-3.2-10.fc9.src.rpm
SPEC: http://www.grid.tsl.uu.se/repos/globus/fedora/9/info/gpt.spec

(In reply to comment #5)

> (It is FHS, not HFS). This patch too should be made acceptable by 
> upstream. It uses configure, so the standard paths could be passed to
> the application. They should be used unless the environment variable
> is set, in which case the environment variable should be used.

I have split the large FHS patch to several smaller ones and submitted them
upstream.

> > > Why do you change _ in - in script file names?
> > 
> > The upstream code is inconsistent in its naming. It has 20 script names that
> > have - and 8 that uses _, for no apparent good reason. Making the naming of the
> > scripts consistent is more userfriendly.
> 
> Maybe, but this is something that should be changed upstream and not in 
> fedora.

OK, I have removed this.

> > > Reading the /usr/share/gpt/lib/perl/Grid/GPT/LocalEnv.pm
> > > file it seems that gtar/gzip is used, so a Requires should be needed,
> > > in stead of the perl(Archive::Tar) Requires. Also rpm and rpmbuild
> > > seems to be used so maybe some Requires are missing.
> > 
> > I have added Requires for tar and gzip. (I did not do that originally since
> > those were listed as exceptions that were not needed to be listed as build
> > requirements. But thinking about it that is not quite the same thing.) The
> > perl(Archive::Tar) requirement is automatically picked up by rpm, and not
> > mentioned in the spec file. And I think it should be there.
> 
> I don't think that perl(Archive::Tar) is used when gtar/gzip is used, so
> it shouldn't be required.

The system tar/gzip is only used for packaging/unpackaging. The Archive::Tar
perl module is still used for extracting metadata about tarfiles, like the
number of files in the archive. (Yes, I did try to filter out the requirement
and the globus build then failed).

> > I did not add any requires for rpm and rpmbuild since their use inside gpt is a
> > rather exotic use of gpt. Using gpt to produce rpms that way will create bad
> > rpms, with no proper sources.
> 
> I don't think it is an issue. If it is what gpt user are used to.

I have added requires on rpm and rpm-build.

> > > Also gpt-bootstrap.sh seems to require all the autotools and it is not
> > > very clear where it is documented.
> > 
> > Yes bootstrapping requires the autotools, but that is normally the case, so I
> > can't see that it requires any special documentation. Please clarify what you
> > meant by this comment, since I don't get what you are suggesting.
> 
> If gpt-bootstrap.sh is meant to be used by gpt users, Requires in gpt
> are needed for the autotools.

I have added requires on autotools (automake, autoconf, libtool). (I hope you
won't reject the package now due to rpmlint complaining about the libtool
requirement.)

> > > Do you really need to rerun the autotools? It doesn't seems clear
> > > to me based on the patches.
> > 
> > Patches change configure.in and Makefile.am, so yes.
> 
> Ah, I missed them. Looking at them they seem simple enough that patching
> configure and Makefile.in additionally would allow not to rerun the
> autotools.

OK, The patches grew quite a bit in order to propagate the changes, but it was
not impossible, so I have done it this way in the new package.

(In reply to comment #6)

> In the next iterations, it could be nice to have in the spec file the 
> the links to the bugzilla you put in Comment #4 in comment near the 
> patch.

Due to the change of maintenance to the Globus Alliance I was asked to resubmit
the patches to the globus bugzilla by the current maintainer. I have put links
to these new bugzilla reports in the spec file.

> I have 2 additional comments regarding the changelog section
> * you should remove %{?dist} from the changelog
> * I personally prefer when there is a blank line between 2 changelog
>   entries, but this is a matter of preference.

OK, done in the new package.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.