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

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


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


Hans de Goede <hdegoede at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|nobody at fedoraproject.org    |hdegoede at redhat.com




--- Comment #8 from Hans de Goede <hdegoede at redhat.com>  2009-02-23 08:38:56 EDT ---
(In reply to comment #7)
> (In reply to comment #6)
> 

<snip>

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

And I still agree :)

> > * 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?
> 

Yes please do it that way, but keep the -devel subpackage and put all the files
in the %files of the devel subpackage. If you then also remove the %files line
itself for the main package, only the subpackage will be build.

This way we have a srpm and specfile name matching upstream, and still have a
-devel extension to make clear this is a devel package

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

Ok.

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

Ok.

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

Please do a new version without the package split, then I'll do a full review
of that one.

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