Bug 437551 - gnustep-make should be noarch?
gnustep-make should be noarch?
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: gnustep-make (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Axel Thimm
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-14 16:42 EDT by Ville Skyttä
Modified: 2008-09-10 02:46 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-10 02:43:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
(Proposed) Updated spec file (3.79 KB, text/plain)
2008-08-14 19:43 EDT, Michel Alexandre Salim
no flags Details

  None (edit)
Description Ville Skyttä 2008-03-14 16:42:07 EDT
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.
Comment 1 Axel Thimm 2008-03-15 08:23:53 EDT
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!
Comment 2 Ville Skyttä 2008-03-16 05:28:32 EDT
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
Comment 3 Ville Skyttä 2008-03-16 05:31:41 EDT
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).
Comment 4 Ville Skyttä 2008-03-17 13:55:12 EDT
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.
Comment 5 Bug Zapper 2008-05-14 02:04:06 EDT
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
Comment 6 Ville Skyttä 2008-07-03 14:37:54 EDT
ping?
Comment 7 Axel Thimm 2008-07-04 17:15:13 EDT
(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*.
Comment 8 Axel Thimm 2008-07-04 17:24:09 EDT
(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.
Comment 9 Jochen Schmitt 2008-07-24 14:29:36 EDT
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.
Comment 10 Michel Alexandre Salim 2008-08-06 05:27:45 EDT
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?
Comment 11 Axel Thimm 2008-08-06 09:18:19 EDT
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).
Comment 12 Michel Alexandre Salim 2008-08-14 19:41:07 EDT
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)
Comment 13 Michel Alexandre Salim 2008-08-14 19:43:04 EDT
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.
Comment 14 Michel Alexandre Salim 2008-08-14 21:31:55 EDT
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?
Comment 15 Axel Thimm 2008-08-16 06:50:46 EDT
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.
Comment 16 Michel Alexandre Salim 2008-08-21 22:22:16 EDT
Sounds like a good idea. Should we perhaps start a GNUstep packaging draft on the Wiki?
Comment 17 Axel Thimm 2008-08-22 05:48:10 EDT
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.
Comment 18 Fedora Update System 2008-08-23 14:50:18 EDT
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
Comment 19 Fedora Update System 2008-08-23 14:50:23 EDT
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
Comment 20 Fedora Update System 2008-09-10 02:43:14 EDT
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.
Comment 21 Fedora Update System 2008-09-10 02:46:51 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.