Hello I do not really see a problem here. All gnustep packages store files in a (at least sort of) FHS compliant directory: /usr/lib/GNUstep
It is not very different from perl, python, emacs, java (and more) packages that have a "filesystem" of it's own and managed there. Java have its in /usr/share/java (java is "cross platform") and other package have similar things. The only thing that can be argued is that the name maybe should be without capital letters, but I do not think that is very important. So I actually can not see that it break FHS, even if it do not make full use of it. Regards, // Ola On Wed, Jul 27, 2005 at 05:48:24PM +0200, Eric Heintzmann wrote: > Hi, > > I already send this message to the debian-release mailing list, but > Steve Langasek suggested me to send it to debian policy. > > Actually, there are in Debian (sarge, etch, sid) more than 50 packages > that are parts of the GNUstep Environment. But there is a big issue with > all of them: none are FHS compliant. > > The development of GNUstep started a long time before the birth of the > File Hierarchy Standard, and since they implemented the OpenStep API, > the upstream developers chose to create their own > NeXTSTEP/OpenStep/MacOSX-like filesystem layout > (http://www.gnustep.org/resources/documentation/User/GNUstep/filesystem_toc.html). > Now, they don't want to change their filesystem layout according to the > Linux FHS, because GNUstep is multi-platforms, Linux and Unix is only a > target > (http://www.gnustep.org/resources/documentation/User/GNUstep/machines_toc.html). > They prefer to keep the same filesystem layout on all platforms > (including Windows and Darwin/MacOSX) . > Notice that Window Maker uses the same filesystem in Debian, even it is > not a GNUstep application. > > Under Debian: > > The System Domain is set to /usr/lib/GNUstep/System/ > Packages install all their stuff here, (including object files, > libraries, and internal binaries, shell scripts, headers, all commands). > > The Local Domain is set to /usr/local/lib/GNUstep/Local/ (with a > symlink in /usr/lib/GNUstep) > Packages install nothing here. Used by admin to build GNUstep > applications locally. > > The Network Domain is set to /usr/local/lib/GNUstep/Network/ (with a > symlink in /usr/lib/GNUstep) > Packages install nothing here. Used for shared stuff. > > The Users Domain is set to ~/GNUstep/ > Packages install nothing here. Used for store users configuration files. > > The problem is simple: > First, gnustep-make which is used to build all others GNUstep package, > install all the stuff according to the GNUstep filesystem layout, and > cannot be set to install stuff elsewhere. > Second, all GNUstep libraries, frameworks and applications expect for > find stuff at a predetermined place. Moving files will just break GNUstep. > > I co-maintain the GNUstep Core packages for more than 2 years, and I > spend a lot of time to find a solution to these problems by moving files > accordingly to FHS, and by symlinking some directories. > After several tests, I have to admit that I am not able to make GNUstep > FHS compliant without breaking it. > And I don't think that is possible, except if upstream developers change > their mind. > > I've found a place to install GNUstep which seems to be FHS compliant: > /opt/GNUstep. > But using /opt for official Debian package is not allowed. (IMHO, it > should be written explicitly into the policy document). > Notice that FHS document just says : /opt is reserved for the > installation of add-on application software packages. > and not says what is a add-on application. > > So, my question is, should GNUstep be removed from Debian ? > > Eric > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- --------------------- Ola Lundqvist --------------------------- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --------------------------------------------------------------- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
