[pkg-GNUstep-maintainers] Re: Conflicts between FHS and GnuStep (was: Bug#256141: addresses: GNUstep Mass Bug Breaks Policy Section 9.1.1)

[Justin Pryzby]

--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 23, 2004 at 08:18:02PM +0200, Andreas Barth wrote:
> [pretty full quote for the wided auditorium]
>=20
> * 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/Version=
s/A/Headers/
> > >are (Obj)C header files, which according to the FHS should be=20
> > >installed
> > >under /usr/include/.=20
>=20
> > 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=
=20
> > and C++ programming languages should be placed.
> >=20
> > Since these headers are part of a gnustep framework (see these=20
> > frameworks like plugins), they are not standard or of general-use and=
=20
> > they don't need to be moved in /usr/include. ( But I agree that=20
> > installing headers  /usr/lib... is not FHS-compliant).
>=20
> >> [...]
> > The problem is that the GNUstep Makefiles system install them at this=
=20
> > place, and expect to find them here and not in /usr/include. (you will=
=20
> > find same problem in all other GNUstep packages).
>=20
> > But the problem is more general, GNUstep uses is own filesystem=20
> > layout, wich is not FHS compliant.
> > (see it here:=20
> > http://www.gnustep.org/resources/documentation/filesystem.ps)
> > Changing this layout implies to break this elegant layout, and to fork=
=20
> > GNUstep make.
>=20
> 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?
>=20
> I can see different ways out (order has nothing to do with
> preference):
>=20
> 1. Agree that
>    | This is where all of the system's general-use include files for the =
C=20
>    | 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
>=20
> 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.
>=20
> 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

--LZvS9be/3tNcYl/X
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBKjvVh7yD3l4ITTYRAtCnAJ9MTY0pDjqiwO4qbOd4NzREutbaXQCeO9FR
o8n95TZIMF2U/cgpzw5rlgw=
=flpO
-----END PGP SIGNATURE-----

--LZvS9be/3tNcYl/X--