[Debian GNUstep maintainers] Re: [Fwd: Re: GNUstep and FHS]

[Hubert Chan]

On Wed, 27 Jul 2005 17:39:22 +0200, Eric Heintzmann <eric at gnustep.fr.st> said:

> Hubert Chan a écrit :
>>  Have you been successful it making it more FHS compliant?
>> (e.g. moving Library/Headers to /usr/include, moving
>> Library/Preferences, Library/Images, etc. to /usr/share, etc.) Is
>> there anything in particular that caused problems?

> Well, the best option is to install GNUstep into /usr/share/GNUstep
> and try to move and symlink some directories.

My gut feeling says that /usr/lib/GNUstep makes more sense, and it would
be easier to symlink the known arch-independent parts into
/usr/share/GNUstep (or maybe /etc for Library/Preferences).  There seems
to be a lot of potentially arch-dependent stuff in Library
(e.g. Library/GNUMail/PGP.bundle/PGP is an arch-dependent binary).
Library/Makefiles also includes some arch-dependent binaries (such as
Library/Makefiles/user_home), although the vast majority of that
directory is arch-independent.  But at least the exceptions in that
directory seem to be few enough that it should be possible to work
around.

My sense is that it's much more forgivable to have arch-independent
stuff in /usr/lib than to have arch-dependent stuff in /usr/share.

[...]

> * Libraries: ...

Yeah, Resources sounds fairly generic to put it in /usr/lib.  (There's
also a Library/Libraries/Java directory, which is empty on my system.)
Maybe changing the search from Resources to something like
gnustep-resources is an easy change in the GNUstep libraries (just
guessing, but it seems reasonable), but that would make us
binary-incompatible with other GNUstep installations.  Unless we make
both paths work.

Other than the linker issue (needing to put /usr/lib/GNUstep... into
/etc/ld.so.conf), though, I'm not sure that it really is necessary to
put all the libraries in /usr/lib, rather than /usr/lib//GNUstep...
There's at least precedent in other packages for putting commonly-used,
but toolkit/environment-specific stuff into a subdirectory.  For
example, /usr/lib/qt3.

> The problems I cannot solve are Applications, Bundles (plugins),
> Frameworks and Services.

That was my guess as to where the big problems were.

> *Applications: ...

There is at least precedent in dumping some arch-independent stuff into
/usr/lib.  (Though if we could put as much arch-independent stuff into
/usr/share and symlink, that would be better.)  For example,
/usr/lib/mozilla-firefox contains some arch-independent stuff.  Also,
/usr/bin/firefox is just a script that basically just sets up the
environment and runs /usr/lib/mozilla-firefox/firefox-bin, which is
similar to the scripts that the GNUstep applications put in /usr/bin.

> *Bundles (Plugins) and Services: ...

Bundles and Services I think fit in /usr/lib/[GNUstep] just fine, I
think, since they are "internal binaries that are not intended to be
executed directly by users or shell scripts".

For that matter, I don't think the <appname>.app binaries are intended
to be executed directly; they are meant to be opened using openapp.  So
putting those in /usr/lib shouldn't be much of a problem, I don't think.

> *Frameworks: ... The best for the end. GNUstep Framework install data,
> libraries (shared only), and headers under a versioned single
> directory. And add symlinks into Library/Libraries (/usr/lib if we
> symlink to it), and Library/Headers (usr/include if we symlink to
> it). The soname versionning is fanciful and doesn't reflect ABI
> change.  Move libraries and they will not find their data and will not
> work.

Yeah, the headers in there look like they will cause some fun.  We would
probably have to use the same sort of versioning in /usr/include.

I think that it should be OK to leave the rest of the frameworks in
/usr/lib/GNUstep.  (Same reasoning as for Libraries.)


I'm not sure if it's possible to make GNUstep completely FHS-compliant.
But if we make it more compliant, it may be more palatable to any
developers who might object to the GNUstep hierarchy, and make it easier
to be granted an exception in policy.

>>> Since there is no other maintainer to try to make these packages FHS
>>> compliant, should GNUstep be removed from Debian ?

>> I would be interested in helping at some point.  But not until at
>> least the middle of next month.

> Thanks. You are welcome.  But, do you really think there is something
> you can do ?

Well, I'm interested in helping out with GNUstep packaging in general.
If FHS compliance is something that I can help with, I would be happy to
help out.  I guess you probably know better than I do whether or not any
help is needed.

It looks to me like the GNUstep team is a bit short on manpower, but I
don't know where the bottleneck is, so I don't know whether or not
there's anything that I can do.  I'm not a DD yet (planning to start the
NM process soon), so I wouldn't be able to help with stuff that requires
an official DD, but I would be willing to help in other areas, if you
need any help.

-- 
Hubert Chan <hubert at uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.