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? And does one centralized package provide all of the directories which need to be moved? If a bunch of packages need to get updated, then I don't think 3. is a good idea. 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/? Justin
Attachment:
signature.asc
Description: Digital signature