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

[bugzilla at redhat.com]

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 pertusus at free.fr  2008-07-09 03:12 EST -------
(In reply to comment #3)

> You are right, gpt is quite useless for most things. Except for building globus.
> The globus build (makefiles and configure files) makes heavy use of gpt macros
> and gpt package dependency description files. Building globus without gpt would
> be possible, but would require a large amount of work to rewrite the build
> instructions.

Ok.


>
http://www.grid.tsl.uu.se/repos/globus/fedora/9/src/SRPMS/grid-packaging-tools-3.2-9.fc9.src.rpm

Looks good.

> http://www.grid.tsl.uu.se/repos/globus/fedora/9/info/grid-packaging-tools.spec
> 
> It is still OK to use /usr/share/gpt as the install location, right? Or must I
> change that to /usr/share/grid-packaging-tools?

You'll need to change it only if another package really needs to use that
name.


> The patches that
> adapt to the HFS file system layout used in Fedora are not really bug fixes but
> packaging adaptations, so not really appropriate to submit to upstream.

(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.

> > 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.

> > 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.
 
> 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.

> > Why aren't the dtds in some dtd directory?
> 
> In the new package I have moved them to /usr/share/gpt/dtd which seems
> consistent with how other Fedora packages install dtd files.

Ok.

> > There are some automake duplicated files, this deserves a comment.
> 
> The files in /usr/share/gpt/amdir are not simple copies of the automake
> versions. They are extended gpt versions with additional build instructions in
them.

Ok.

> > 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.

> > the globus_core-src.tar.gz file seems also dubious to me.
> 
> Removed in the new package.
> 
> > 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.



-- 
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.