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

[Hubert Chan]

On Fri, 29 Jul 2005 23:25:25 +0200, Eric Heintzmann said:

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

...or the policy team (or maybe it needs to go through a GR?) ...

>> [...]

>>> * Libraries: ...

[...]

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

Yes.  I just wasn't sure if putting /usr/lib/GNUstep... into
/etc/ld.so.conf is something that people have complained about.

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

It may be an issue of amount in some peoples' eyes.  e.g. if GNUstep
encourages putting arch-indep stuff into /usr/lib, then that affects a
lot of packages, and includes a lot of files.  Whereas
/usr/lib/mozilla-firefox, etc, are just single packages, with fewer
files.

Nevertheless, I agree that if it's a policy violation for GNUstep to do
it, then it should be a policy violation for firefox and OOo to do it.

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

(Yeah, I was just being sloppy.  I guess I should have said
<appname>.app/<appname>.)

>>  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 ?)

/usr/share/GNUstep doesn't sound like the right place -- there may be
other Objective C headers that aren't GNUstep-related.

IMHO, I'm not sure that Objective C is so different from C or C++ that
its headers should be placed somewhere else.  If gcc includes
/usr/include in its search path for Objective C headers, and doesn't
have any other special default search path for Objective C headers, then
I think that /usr/include is fine.  At least, I can't imagine that
anyone would complain if we put them there.

> After reflexion, I think if we just use /usr/lib/GNUstep and
> /usr/lib/GNUstep

I assume you meant "/usr/lib/GNUstep and /usr/share/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).

I agree.  And I would also be interested in Gürkan's opinion.

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

Alright.  I just don't want to step on anyone's toes, and duplicate
work.  (I guess the purpose of this mailing list is to coordinate the
packaging effort.)

Is there a CVS/SVN/Arch repository that I should be looking at with
respect to packaging?  Or is everything done separately?

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

Well, uploading requires a DD.  I wasn't sure if that was the only
bottleneck -- if it was, then I wouldn't be of any help.  But I guess it
isn't so I'll take a look at what I can do.  (Although, like I said, not
until middle of next month -- I'm going to be out of town for a bit.)

> In my opinion, GNUstep Core , Gorm, ProjectCenter, GWorkspace, GNUMail
> need help.  And probably Etoile when ready.

OK.  What sort of help do they need?  I also noticed that there were
some orphaned packages (Brent's and Evan's).  I'll look at those too.  I
noticed that steptalk (one of Brent's old packages) has an RC bug that
is fixed by a simple patch.

-- 
Hubert Chan <hubert at uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.