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@xxxxxxxxxxxx 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review