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@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|nobody@xxxxxxxxxxxxxxxxx |hdegoede@xxxxxxxxxx --- Comment #8 from Hans de Goede <hdegoede@xxxxxxxxxx> 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review