[Debian GNUstep maintainers] Re: RFS: GNUstep packages

[Hubert Chan]

[removing -mentors from Cc: since this tread doesn't really concern them
any more]

On Fri, 09 Dec 2005 23:27:57 +0100, Gürkan Sengün said:

[...]
 
>>> - why do you conflict libgmp?
>> 
>> That was something Eric added.  Gnustep-base shouldn't be built with
>> libgmp3.

> ok there was probably a reason for it...

Eric wrote this when I asked him about it a while ago:

,----
| See this thread:
| 
| http://lists.gnu.org/archive/html/help-gnustep/2004-10/msg00017.html
| 
| Notice that I removed libgmp-dev dependency in Oct 2004 (see changelog
| from 25 Oct 2004).
| I now add libgmp3-dev into Build-Conflicts field to avoid accidental
| linking.
`----

[...]

>>> - can you make a tool, say gnustep-fhs on|off that undoes what
>>> fsdh_gnustep does? or at least log fsdh_gnustep stuff in a way it
>>> can be undone?
>> 
>> Are you talking about turning off gsdh_gnustep at build time, or
>> after undoing the changes after the package has been installed?  For
>> turning off gsdh_gnustep at build time, I can add a check that checks
>> for some environment variable being set, and just exits without doing
>> anything if the variable is set.  (Or you can rebuild gnustep-make to
>> install a version of gsdh_gnustep that is just an empty script.)  For
>> undoing the changes after the package has been installed, that would
>> probably be harder.

> any of them are fine. being able to change it without the need to
> rebuild,install packages would of course be much betteer. but i'm
> probably the only one wanting this...

Changing it on an already-installed package (i.e. installing the
package, and then moving the files around) is probably asking for
trouble, since it will increase the likelihood of certain things
breaking.

For changing things without rebuilding, one possibility is to set up a
script that uses dpkg-deb to extract the package, move the files back to
their original locations, and use dpkg-deb to repack the package.  It'll
take some time to write, though, so I'm not going to promise anything
soon.

I can change gsdh_gnustep to check for the environment variable
"DEB_GNUSTEP_NO_MOVE", and exit without doing anything if that variable
is set.  And if you're building a system where you don't want the files
to be moved, it would be easy to just modify gnustep-make to install
gsdh_gnustep as an empty script.  The only tricky thing is to make sure
that GNUstep packages work properly both with and without the file
relocations.  Most packages should be fine, but some might require a bit
of care.  (In particular, things like dh_install should be called before
gsdh_gnustep.)

>> My thought was to create a repository in our alioth project, instead
>> of putting it in experimental, since it would be easier for us --
>> since most of us are not DDs (yet).  But yes, it would make sense to
>> put them in some test-repository, before we upload to unstable.

> i would really prefer it in experimental. but i'd love it in sid most.

Yes, sid will be the eventual goal.  We just need to make sure that we
coordinate with debian-release, to make sure that we don't hold up the
other library transitions (and make them angry).

If there are no problems with uploading in experimental (i.e. we all
have sponsors willing to do the uploading for us), then experimental
would be better than alioth.

> btw: there will probably be a new gnustep tarball release soon.  do
> you see a chance to also create gnustep-cvs versions once the latest
> tarball is in sid. to have cvs ones in experimental?

Yes, I think that would be good.

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