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.
* Headers:
Symlinking Library/Headers dir to /usr/include. No problems.
* Tools:
Symlinking Tools dir to /usr/bin. No real problem: packager will have to
check their package for sys admin tools and move them by hand into
/usr/sbin.
* Libraries:
Symlinking Library/Libraries dir to /usr/lib. But it means adding a
Resources symlink into /usr/lib (no other options). I'm not sure but
Resources seems a bit generic.
Maybe we can go round the obstacle by symlinking Library/Libraries to
/usr/lib/GNUstep/Libraries (for example) and symliking Resources elsewhere.
All of this can be see as an improvement of the FHS-compliance, but in
facts nearly all GNUstep packages are not libraries, tools or headers.
>
>>From what I can tell, it's not possible to make GNUstep completely FHS
> compliant without a lot of upstream help. But it looks like we should
> be able to make it more compliant than it currently is.
The problems I cannot solve are Applications, Bundles (plugins),
Frameworks and Services.
All GNUstep packages except gnustep-make, gnustep-base and gnustep-gui
are applications or frameworks and contains bundles (plugins).
*Applications:
All GNUstep Apps install all their files into a single directory (called
<appname>.app).Executable and data files are mixed under this directory.
If you move the executable to /usr/bin, it will not find its data and
will not work. ( and also you will no more able to copy an app to
another computer just by copying the <appname>.app dir, that it can be
see as breaking GNUstep specs)
*Bundles (Plugins) and Services:
GNUstep install Bundles and Services into a single directory.
Executable, libraries and data files are mixed under this directory.
If you move the executables to /usr/bin, and libraries to /usr/lib, they
will not find their data and they will not work.( and also you will no
more able to copy a bundle or a service to another computer just by
copying the dir, that it can be seen as breaking GNUstep specs)
*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.
>
>
>>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 ?
Eric
PS
I suggest to not continue this thread in debian-release mailing list.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
