[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Conflicts between FHS and GnuStep

Justin Pryzby wrote:

On Mon, Aug 23, 2004 at 08:18:02PM +0200, Andreas Barth wrote:


[pretty full quote for the wided auditorium]

* Eric Heintzmann (eric.h@no-log.org) [040807 10:55]:


On 2004-07-30 11:58:18 +0200 Steve Langasek <vorlon@debian.org> wrote:


There does appear to be a policy violation here.  The files installed
under
/usr/lib/GNUstep/System/Library/Frameworks/Addresses.framework/Versions/A/Headers/
are (Obj)C header files, which according to the FHS should be installed under /usr/include/. 


The FHS says:
4.3 /usr/include : Directory for standard include files.
This is where all of the system's general-use include files for the C and C++ programming languages should be placed.
Since these headers are part of a gnustep framework (see these frameworks like plugins), they are not standard or of general-use and they don't need to be moved in /usr/include. ( But I agree that installing headers /usr/lib... is not FHS-compliant). 


[...]
The problem is that the GNUstep Makefiles system install them at this place, and expect to find them here and not in /usr/include. (you will find same problem in all other GNUstep packages).
But the problem is more general, GNUstep uses is own filesystem layout, wich is not FHS compliant. (see it here: http://www.gnustep.org/resources/documentation/filesystem.ps) Changing this layout implies to break this elegant layout, and to fork GNUstep make. 

Ok, we're now pretty near to a release, and this RC-bug is open for
some time, so my question is: How to continue?

I can see different ways out (order has nothing to do with
preference):

1. Agree that
| This is where all of the system's general-use include files for the C | and C++ programming languages should be placed. 
  doesn't match GNUstep files, and leave everything as is.
2. Accept the location of GNUstep files as an exception for sarge, and
  change that post-sarge.
3. make a lot of changes to GNUStep in the last minute
4. drop GNUStep from sarge

I don't have any real opinion on it, except that dropping would be a
pity, and I don't like over-hurrying. So, I'd go for 1 or 2.

Of course, you might disagree, and IMHO the RMs have the last say.
However, I think there should be some discussion by next weekend, so
that we know where we are going to.



Yes that does look messy.  Tell me; how many things would have to get
moved for FHS compliance? 
Well GNUstep uses its own makefile system.
All stuff is automatically installed under /usr/lib/GNUstep/System/...
Some subdirectories contains arch-independent data only: they could be symlinked in /usr/share. But all others subdirectories mix arch-independent data with arch-dependent data. All files should be checked and symlinked in /usr/share one by one and by hand. This is a huge work that should be done in all GNUstep packages (> 40 source package) and of course all package should be rechecked with all new upstream releases. I think is best to work with upstream to add FHS support to the GNUstep Makefiles system. 




And does one centralized package provide
all of the directories which need to be moved?

Yes, it does. The centralized package is called gnustep-make.
And modify it means rebuild all GNUstep packages.


If a bunch of packages need to get updated, then I don't think 3. is a
good idea. 
Yes, I agree.
 If not, (that is, if there's a single gnustep package

which provides all those noncompliant directories, which are used by
other gnustep packages) then it shouldn't be too hard to change.

I've had to do similar in a nonfree package I'm maintaining
(unofficially; IRAF).  It too lives in a dedicated directory
hierarchy.  I now have appropriate directories in /usr/share, where
the IRAF root is /usr/lib.  A handful of symlinks in each is all
that's needed to allow everything to find itself.

Is the primary problem here moving stuff to a /usr/share/ hierarchy
rather than /usr/lib/?
The primary problem is that GNUstep uses its own Filesystem Hierarchy that does not comply with FHS. 
(For more detail about the GNUstep Filesystem Hierarchy see:
http://www.gnustep.org/resources/documentation/filesystem.ps)

Eric
Reply to: