While looking at current Rawhide's debuginfo packages, I found that gnustep-make's is empty. Examining the main package's contents makes me think that the package should be noarch - there are no native binaries or libs and apparently lib/lib64 path differences either.
In gnustep-make 1.x there was a binary (/usr/libexec/gnustep/which_lib) that enforced this. With 2.x there are no bionaries anymore, but gnustep still wants to keep Makefiles for different archs in different directories. E.g. there are indeed different paths in the two packages (actually counting ppc in all three). One can investigate whether this is a proper assumption by gnustep, but I'm not that deep into the matter to rule out the necessity of having packages depending on gnustep-make store their Makefiles into different parts of the fs. If the Makefiles need to reference binaries then the assumption is correct and making gnustep-make noarch would break these. Closing as NOTABUG, but if some gnustep expert knows better, please reopen and advise accordingly, thanks!
Oh, I missed that. However, that being the case, the debuginfo package should be disabled (%define debug_package %{nil}). Also, I don't know about whether it's a problem, but I see the host and cpu in config-noarch (note *noarch*) get defined to that of the build target, which sounds suspicious to me. For example: In the ppc package's /usr/share/GNUstep/Makefiles/config-noarch.make: GNUSTEP_HOST = powerpc-redhat-linux-gnu GNUSTEP_HOST_CPU = powerpc In the x86_64 one: GNUSTEP_HOST = x86_64-redhat-linux-gnu GNUSTEP_HOST_CPU = x86_64
So if GNUSTEP_HOST and GNUSTEP_HOST_CPU from config-noarch.make are actually ever used by something, this is most certainly a problem too and the files should be moved away from /usr/share, probably to %{_libdir} (or the variables emptied if possible).
Actually, come to think of it, I suppose this package should not install stuff into /usr/share in the first place. From the Fedora POV, the point of installing to /usr/share is that the dir can be (NFS) mounted on a bunch of machines of varying architectures running the same distro version. In rpm world that's coupled with %{_netsharedpath} /usr/share. Now, if the NFS server runs let's say x86_64 and this package is installed on it, PPC and i386 hosts with %{_netsharedpath} /usr/share have it installed too (%{_netsharedpath} causes no files actually installed in it) can access the package's contents in their /usr/share which comes from the x86_64 server, but have no PPC or i386 specific files available -> borkage. So I suppose leaving the package as arch specific but moving stuff from /usr/share to %{_libdir} (and disabling the empty debuginfo package) would sound like a valid plan.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
ping?
(In reply to comment #2) > Also, I don't know about whether it's a problem, but I see the host and cpu in > config-noarch (note *noarch*) get defined to that of the build target, which > sounds suspicious to me. For example: The reason for GNUstep doing so is goven in the lines right before that: # If multi-platform support is disabled, just use the hardcoded cpu, # vendor and os determined when gnustep-make was configured. The # reason using the hardcoded ones might be better is that config.guess # and similar scripts might even require compiling test files to # determine the platform - which is horribly slow (that is done in # names.make if GNUSTEP_HOST is not yet set at that stage). To # prevent this problem, unless we were configured to determine the # platform at run time, by default we use the hardcoded values of # GNUSTEP_HOST*.
(In reply to comment #4) > Actually, come to think of it, I suppose this package should not install stuff > into /usr/share in the first place. I checked the inline documentation and also the latest version (which fixes all outstanding FHS issues). I think the intention is to have shareable code all over. It allows for different combos, some of which may be platform dependent and therefore creating platform specific folders in a shareable way. Following the guidelines to the letter means that one would have to move config.make to %{_libexecdir} or %{_libdir}, but I'm not sure how fragile gnustep-make using software may become to such a split. I'll do some more thinking while packaging 2.0.6 and see whether it gets split, moves as a whole or maybe stays that way and gets an UPSTREAM request.
I thing this package shouldn't be noarch, I have tried to compile gnustep-base and have to find out, that the linker tried to link agains /usr/lib. On a x86_64 system, the linker should links agains /usr/lib64. The reason for this issue are the wrong path in GNUstep.conf which belongs to gnustep-make. As an addtional info, the release 2.0.6 of gnustep-make is available.
Seems like combining non-flattened and FHS layout is a bad idea -- the non-flattened layout (i.e. fat binaries) is intended to be used with the GNUstep layout. Given the lib/lib64 issue, should we just use a flattened layout for now?
Ville's comment #4 made a lot of sense, and while it is not gnustep's intention we will have to package it that way for now. Maybe in the future gnustep-make manages to get back to datadir, but not with 2.0.6. As to a flat hierarchy (comment #10): I think the changes fix this, so we don't need to flatten it out. I wouldn't want to flatten it as we would have to make a choice between building gnustep-base and opengroupware.org (the (non-)flattened layout does not only cater for arch, but for more).
There is one problem with using --fhs together with --disable-flattened: while putting arch-specific library files into /usr/lib/$ARCH is fine, doing the same with /usr/bin/$ARCH is problematic as /usr/bin/x86_64 is a file belonging to util-linux-ng. Seems like we should either make an exception and use the proper GNUstep layout, or use the FHS completely. This is what gnustep-base contains when built against gnustep-make with the current settings /usr/bin/x86_64/* /usr/lib/GNUstep/DTDs /usr/lib/GNUstep/Libraries /usr/lib/x86_64/* In the meantime, I cleaned up the spec file a bit (attached). I tidied up the file a bit, dropped the perl build requirement (using sed for all the required changes) and fixed a UTF-8 warning. The license correction that Tom Callaway made (gnustep-make is GPLv3+) has been re-added, and debuginfo generation has been suppressed. Let me know if it looks fine and I'll commit it. We need to resolve the /usr/bin/x86_64 problem one way or another, though. Either this is a util-linux-ng bug, or we cannot combine fhs and no-flatten. (Will post my review requests for gnustep-base and oolite once the path issue is resolved)
Created attachment 314362 [details] (Proposed) Updated spec file I bumped up the release number here, but we might want to reset this to 1 next time a new version of gnustep-make is out? That appears to be the Fedora convention; the last time I see the release number increasing across version numbers is with SUSE.
Review request for gnustep-base: https://bugzilla.redhat.com/show_bug.cgi?id=459210 This blocks #459211, review request for Oolite, a cross-platform sim game originally written for Mac OS X and ported using GNUstep, and #459212, the data files for Oolite. Depending on what the final file-system layout we settle on is, I might have to rework the packages a bit. Currently, for gnustep-base I simply move all the binaries to /usr/bin (note that sourcing %{_libdir}/GNUstep/Makefiles/GNUstep.sh will still add /usr/bin/$ARCH/... to the path, which on Fedora and RHEL is meaningless since util-linux-ng, which is a core package, prevents those directories from ever being made). Having multilib turns out to actually be quite nice, so I'm a convert to --disable-flattened. Should we file a bug against util-linux, then, or just simply not use the /usr/bin/$ARCH hierarchy for now?
We need to stay with FHS and fix anything gnustep-* didn't yet properly FHS'ize. %{_libdir}/<combo> should probably become %{_libdir}/GNUstep/<combo> and %{_bindir}/<combo> sound like it should be placed under %{_libexecdir}/GNUstep/<combo> with optional symlinks to %{_bindir}. Maybe this needs some FPC guideline.
Sounds like a good idea. Should we perhaps start a GNUstep packaging draft on the Wiki?
Then let's move the discussion to either fedora-devel or more probably fedora-packaging. I'd like to close this bus as the original issue has been dealt with and we're now discussing more fundamental issues. Once we lay out a sane gnustep -> FHS/Fedora mapping gnustep-make will have to be modified accordingly, of course.
gnustep-make-2.0.6-12.fc8 has been submitted as an update for Fedora 8. http://admin.fedoraproject.org/updates/gnustep-make-2.0.6-12.fc8
gnustep-make-2.0.6-12.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/gnustep-make-2.0.6-12.fc9
gnustep-make-2.0.6-12.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
gnustep-make-2.0.6-12.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.