[Debian GNUstep maintainers] Re: [Fwd: Re: GNUstep and FHS]

[Gürkan Sengün]

> >My gut feeling says that /usr/lib/GNUstep makes more sense, and it would
> >be easier to symlink the known arch-independent parts into
> >/usr/share/GNUstep (or maybe /etc for Library/Preferences).  There seems
> >to be a lot of potentially arch-dependent stuff in Library
> >(e.g. Library/GNUMail/PGP.bundle/PGP is an arch-dependent binary).
> >Library/Makefiles also includes some arch-dependent binaries (such as
> >Library/Makefiles/user_home), although the vast majority of that
> >directory is arch-independent.  But at least the exceptions in that
> >directory seem to be few enough that it should be possible to work
> >around.
> >
> >My sense is that it's much more forgivable to have arch-independent
> >stuff in /usr/lib than to have arch-dependent stuff in /usr/share.

Forget it splitting stuff into /usr/lib and /usr/share will break it badly.
The /Network domain must stay at the same place. It must be NFS exportable.
GNUstep supports FAT Binaries (read about that on NeXTSTEP/OPENSTEP docs).

> You are probably right. But this the decision of the Debian release team.
> >>* Libraries: ...
> >Yeah, Resources sounds fairly gneric to put it in /usr/lib.  (There's
> >also a Library/Libraries/Java directory, which is empty on my system.)
> >Maybe changing the search from Resources to something like
> >gnustep-resources is an easy change in the GNUstep libraries (just
> >guessing, but it seems reasonable), but that would make us
> >binary-incompatible with other GNUstep installations.  Unless we make
> >both paths work.
> > though, I'm not sure that it really is necessary to
> >put all the libraries in /usr/lib, rather than /usr/lib//GNUstep...
> >There's at least precedent in other packages for putting commonly-used,
> >but toolkit/environment-specific stuff into a subdirectory.  For
> >example, /usr/lib/qt3.
> I'm agree, if  accepted it would easier to keep libraries under
> /usr/lib/GNUstep.

If the urge us to improve. I came up with a fantastic idea how we
can make more users happy: change the GNUstep root from /usr/lib/GNUstep
into just / . so we can have our stuff right at /System, /Network
and /Local.

Later the FHS, must be fixed. Their broken standard must be extended.

> I agree. (But <appname>.app are not binaries but directories with binary
> and data files).

We call those bundles.

> >>*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.
> >Yeah, the headers in there look like they will cause some fun.  We would
> >probably have to use the same sort of versioning in /usr/include.
> The FHS seems to say that /usr/include is for C or C++ headers.
> Maybe Objective C headers should be put elsewhere (in /usr/share/GNUstep ?)
> >I think that it should be OK to leave the rest of the frameworks in
> >/usr/lib/GNUstep.  (Same reasoning as for Libraries.)

You know playing with these things will put Eric into hell and
give him a nightmare? I second what Anton Zinoviev says.

> >I'm not sure if it's possible to make GNUstep completely FHS-compliant.
> >But if we make it more compliant, it may be more palatable to any
> >developers who might object to the GNUstep hierarchy, and make it easier
> >to be granted an exception in policy.

It's not possible. Why not simply have a tag or something like
non-fhs (sure it's messy) -> but some people just don't give a shit
about FHS - frankly.

> After reflexion, I think if we just use /usr/lib/GNUstep and
> /usr/lib/GNUstep we can easily improve the FHS compliance (but not
> fully). Using symlinks we can preserve the GNUstep hierarchy.
> Gürkan, what do you think ?

Symlinks are a mess, they don't exist on some systems. Sure, you
can now say Debian doesn't support systems that don't support symlinks.
If we go for symlinks, let's make sure the whole app bundle stays complete
and outside of its directory things link to it -> this is important
for /Network domain things, that people might NFS export to other systems.

> Your opinion is important (at least for me).

Thank you. I'm all for breaking none to minimal things of GNUstep.
The symlinks is the cheap solution. And putting the files
across the unix filesystem (FHS) is no solution.

> >Well, I'm interested in helping out with GNUstep packaging in general.
> >If FHS compliance is something that I can help with, I would be happy to
> >help out.  I guess you probably know better than I do whether or not any
> >help is needed.
> Any help is welcome, really.

What about you join us at irc.gnustep.org #gnustep . there's plenty of
things to do, and talk about.

> >It looks to me like the GNUstep team is a bit short on manpower, but I
> >don't know where the bottleneck is, so I don't know whether or not
> >there's anything that I can do.  I'm not a DD yet (planning to start the
> >NM process soon), so I wouldn't be able to help with stuff that requires
> >an official DD, but I would be willing to help in other areas, if you
> >need any help.

currently it's the FHS issue, if that is solved, i'd be glad when
you helped with packaging gnustep software and also apply to get DD
so you can sponsor gnustep packages ;)

> Nothing requires to be a DD. I'm not DD too.
> In my opinion, GNUstep Core , Gorm, ProjectCenter, GWorkspace, GNUMail
> need help.
> And probably Etoile when ready.

Same here, I'm not DD too.

Yours,
Gürkan