Francesco P. Lovergine wrote:
Sounds fine to me. This bug can probably be easily taken care of by hacking the gnustep-make programs. Since they follow the same design principle you can just have it use different directories.On Tue, Jun 22, 2004 at 04:14:36AM -0400, Dan Weber wrote:Jérôme Warnier wrote:Le mar 22/06/2004 à 05:35, Dan Weber a écrit :There is a serious policy violation regarding all programs dependant upon gnustep-base1 and themselves. They break Section 9.1.1 of the Debian Policy.Using /usr/lib/GNUstep for non-lib and executable binaries for direct invocation is not permitted.Mozilla and OpenOffice.org also violate the FHS in a similar way. The packagers say that for such huge applications, having files all around the system is more a problem than violating FHS. [..]Why should we let this go by? The Debian Policy sets rules for all packages not just some, thus similar bugs should be filed against mozilla and openoffice.org.For instance because many huge programs are built by defining an APPLICATION_DIR and creating a complicated tree of other dirs there, with a large mess of libs, bins and data all mixed together. This is a very traditional approach in the *nix world. Moving from that approach could require heavy patching. You know, not allprograms are written with the needed flexibility and some of them are multi-platform (e.g.mozilla, ooffice) and need to find bad arch compromises for non-nix worlds. That's forgeneral theory...In the specific case you point, files could be probably moved in the right places and a sym link could be created in /usr/lib/<app>to avoid breaking the application. That will be used 'internally' and so will be ok by the FHS pov.
Dan Weber
Attachment:
signature.asc
Description: OpenPGP digital signature