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

[Eric Heintzmann]

Hubert Chan a écrit :

>
>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.
>  
>

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.
>
>Other than the linker issue (needing to put /usr/lib/GNUstep... into
>/etc/ld.so.conf),
>
The gnustep-make postinst script already do that. Not a problem.

> 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.

> There is at least precedent in dumping some arch-independent stuff into
>
>/usr/lib.  (Though if we could put as much arch-independent stuff into
>/usr/share and symlink, that would be better.)  For example,
>/usr/lib/mozilla-firefox contains some arch-independent stuff.  Also,
>/usr/bin/firefox is just a script that basically just sets up the
>environment and runs /usr/lib/mozilla-firefox/firefox-bin, which is
>similar to the scripts that the GNUstep applications put in /usr/bin.
>  
>

It seems that is allowed for others is not allowed for GNUstep (see Ola
post in debian-policy).

>  
>
>>*Bundles (Plugins) and Services: ...
>>    
>>
>
>Bundles and Services I think fit in /usr/lib/[GNUstep] just fine, I
>think, since they are "internal binaries that are not intended to be
>executed directly by users or shell scripts".
>
>For that matter, I don't think the <appname>.app binaries are intended
>to be executed directly; they are meant to be opened using openapp.  So
>putting those in /usr/lib shouldn't be much of a problem, I don't think.
>  
>

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

>  
>
>>*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.)
>  
>
>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.
>
>  
>
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 ?
Your opinion is important (at least for me).


>
>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.

>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.
>
>  
>
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.

    Eric