[Debian GNUstep maintainers] Re: [Fwd: Re: GNUstep and FHS]
Hubert Chan
hubert at uhoreg.ca
Sat Jul 30 20:44:40 UTC 2005
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.
More information about the pkg-GNUstep-maintainers
mailing list