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