[Debian GNUstep maintainers] Re: evening courses

[Hubert Chan]

On Wed, 31 Aug 2005 09:25:51 +0200, Gürkan Sengün said:

> Hello Hubert,
>> OK.  Of the packages that list the mailing list as the maintainer,
>> who "owns" which packages?

> You can look that up at http://packages.debian.org/THEPACKAGE or
> apt-cache show package | grep ^Maint

I meant the packages that list the maintainer as
pkg-gnustep-maintainers at lists.alioth.debian.org,

# apt-cache show libgnustep-gui0.9 | grep ^Maint
Maintainer: Debian GNUstep maintainers <pkg-gnustep-maintainers at lists.alioth.debian.org>

(see
  http://qa.debian.org/developer.php?login=pkg-gnustep-maintainers@lists.alioth.debian.org
for the list of packages.)
Should I take the Uploaders: field to be fairly accurate?

>> Also, who do I bug to do uploads?  Is there a DD on this list, or do
>> I need to find a sponsor?
>> 
>> I've started to take a look at the FHS issues, and I've started to
>> formulate a plan: I think someone, in some message, suggested that
>> GNUstep should use /usr/lib/gnustep as its root instead of
>> /usr/lib/GNUstep.  I forget why it was suggested, but this would make
>> migration to the new layout easier.

> I don't think /usr/lib/gnustep is good. It's really GNUstep.  If you
> can find out why it was suggested we could discuss it.

I'll try to locate the mail in which it was brought up.  IIRC, it was
only mentioned once, and briefly.  I may be mistaken, though; there are
several other packages that have mixed-case directories in /usr/lib
(e.g. AbiWord, to pick the first that shows up on my system).

> I don't see any reason why gnustep would make the migration easier
> instead of GNUstep.

I would imagine that, e.g. if Gorm is already installed, and has the
files /usr/lib/GNUstep/System/Library/Documentation/Gorm*.html, then the
gnustep-base (or whatever) package can't just replace
/usr/lib/GNUstep/System/Library/Documentation with a symlink to
/usr/share/GNUstep/Documentation.  I'm not sure exactly what would
happen, but I can't imagine that it would be pretty.

I prefer /usr/lib/GNUstep too, so I'll think about what would be the
best way to solve this issue.  I think the only way would be to make
gnustep-base/gui/back/make Conflict: with old versions of almost every
GNUstep package, although it may be sufficient to just Conflict: with
the old versions of gnustep-base/gui/back/make.  One more thing to try
out.  (Unless someone already knows the answer.)

>> File relocations are outlined in more detail at:
>> http://www.uhoreg.ca/programming/debian/gnustep/locations.text
>> (warning: it's very rough notes right now, so it might not make much
>> sense to anyone else).  But the shorter version is: In general,
>> arch-indep directories within System/Library get moved to
>> /usr/share/gnustep, and we add a symlink.  System/Library/Headers is
>> moved to /usr/include/gnustep/Headers and we add a symlink.  Headers
>> and Resources within Frameworks get moved to appropriate places in
>> /usr/include/gnustep and /usr/share/gnustep.  The .so* files within
>> System/Library/Libraries can be moved to /usr/lib.  They seem to be
>> able to find their data within System/Library/Libraries/Resources
>> (which will be a symlink to /usr/share/GNUstep/Libraries) without any
>> problems.  This also allows us to get rid of the entry in
>> /etc/ld.so.conf.

> that is so ugly and wrong. but if it works, nice. nice for debian,
> nice for fhs. not nice for GNUstep.

The location of the .so* files was something Steve Langasek specifically
objected to, so it's probably something that needs to be done.  We can
probably keep compatibility symlinks in System/Library/Libraries too,
instead of just moving the files, if that would make it more
GNUstep-friendly.

> i've built gnustep core packages with / as root (the new tarballs),
> http://gnu.ethz.ch/debian/gnustep/ (it's the first build, i know they
> are not perfect, but i will keep working on these)

>> info files and man files should go into /usr/share/info and
>> /usr/share/man respectively (unless anyone knows of any reason they
>> should be in System/Library/Documentation/info and .../man).  Other
>> documentation should go in /usr/share/doc/<package>, with appropriate
>> symlinks created in /usr/share/gnustep/Documentation.  I've tested
>> this out by manually moving the files around within a chroot
>> environment, and it seems to work fine.  Next step is to start
>> building packages of the new upstream releases of GNUstep core, along
>> with some applications, and try to get it to use the new layout.  I'm
>> thinking that the easiest thing to do is to just move things around
>> in the debian/rules install target, instead of trying to edit
>> gnustep-make.  (Actually, I'd like to eventually make a cdbs class
>> that does everything.)  This also has the additional advantage that
>> we won't mess up any users' attempt to compile their own GNUstep
>> programs.

> if you do this, can't you make a flag for the user to easily rebuild
> it all with / as root and ~/ ?

Are you talking about if someone wants to build their own Debian package
with different roots?  I don't think it should be too hard to set up
something where the user can specify their root in debian/rules, and
debian/rules won't perform the relocations if the environment variable
NO_UGLY_DEBIAN_HACKS is set.

>> Any comments or flames?  With the above relocations done, I think the
>> GNUstep Debian packages will be very close to FHS and Debian Policy
>> compliant.

> have you tried to build any gnustep software (apps, tools) and
> installing them to user domain, network domain, system domain and
> local domain?

I haven't tried it with the relocated files yet.

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