[Bug 453848] Review Request: globus-core - Globus Toolkit - Globus Core

bugzilla at redhat.com bugzilla at redhat.com
Mon Feb 16 16:30:09 UTC 2009


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


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





--- Comment #7 from Mattias Ellert <mattias.ellert at fysast.uu.se>  2009-02-16 11:30:07 EDT ---
(In reply to comment #6)

> MUST FIX:
> ---------
> * Add a comment explaining how to get the Source0 tarbal, so people who want
>   to verify its contents against the original can do that

The source was extracted from the globus distribution tarball:

http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2

using this script:

http://www.grid.tsl.uu.se/repos/globus/scripts/split-release.sh

I should be able to think up a short comment along those lines (and reuse it
for the other globus packages.)

> * s390x is a 64 bit arch also

I'll add it

> * since the devel subpackage requires the main package there is no need for it
>   to own directories which are also owned by the main package

OK I'll fix that. (I previously saw some problems with left-behind orphaned
directories, but I can't seem the reproduce those problems now.)

> SHOULD FIX:
> -----------
> * rpmlint warning:
> globus-core.src: W: mixed-use-of-spaces-and-tabs (spaces: line 116, tab: line
> 1)

This is the same thing as in the grid-packaging-tools package - I still think
this is a false positive.

> * How did you come to the devel / non-devel split. Atleast the aclocal and
> doxygen
>   files look like devel files to me. Only files which are needed to *run*
> globus
>   tk using applications should be in the main package, the rest should all be
> in
>   the devel package

The globus-core package is very different from the rest of the globus packages.
All of globus-core is devel, none of it is needed at runtime. I did the split
so that architecture independent files are in the main package and the
architecture dependent files are in the devel-package. For a i386 on x86_64
installation you could then install main + devel from x86_64 and devel from
i386. I found that to be the most natural split if a split should be done.
Thinking about it, it might make more sense to just put all the files in main
and not split it into subpackages. You could then still install both i386 and
x86_64 together since the common files would be exactly the same. Is more
sensible?

> * Given the short list of files in the package I see no need for all the magic
>   to generate filelists. Why not just add everything manually (with wildcards)
>   to %files, that way it is much clearer what is going on

There is no magic here. The split between packages is automatically defined by
gpt. What is done is simply a format conversion form the gpt filelist format to
the rpm filelist format. I agree that in the case of globus-core, which is not
split in so many sub packages you don't gain a lot. The gain is much more
noticeable in packages that generate four or five sub packages. From a package
maintainability point of view it is however much easier to use the same
packaging instructions for all globus packages, though it is a slight overkill
for globus-core.

> * Why do you filter out the requires on the gpt modules, the -devel package
>   requiring gpt is fine, and if the main package gets auto requires for gpt
>   that feels like a hint that the package is not split properly.

As I said, all of globus-core is really devel. No non-devel package requires
globus-core. However all globus-*-devel packages require globus-core and If you
install a globus-*-devel package for anything else than building other globus
packages you don't need gpt. I really don't like having gpt being dragged in by
anything. I consider this a major feature of the packaging.

I didn't prepare a new package yet, since you indicated that you might have
additional comments already. Let me know if you want me to create a new package
version at this stage.

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




More information about the Fedora-package-review mailing list