[Debian GNUstep maintainers] Re: RFS: GNUstep packages

[Gürkan Sengün]

On 2005-12-09 19:18:40 +0100 Hubert Chan <hubert at uhoreg.ca> wrote:

>> - gnustep-back depends on dpslib which it shouldn't, afaik we only
>>    support gnustep backart backend
> 
> Yes.  That was probably an old dependency that got left in there.  I'll
> try building without the dependency.

thanks

>>    please document antaialiasing defaults in README.Debian, check
>>    http://www.linuks.mine.nu/gnustep-settings/
> 
> Sorry, I'm not sure exactly what you want me to document, and I'm not
> sure how that page relates.  Are you saying that I should document the
> fact that antialiasing is enabled by default, and explain how to turn it
> off?

yes, exactly what i mean.
 
>> - 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...

>> - it's not the latest gnustep tarballs
>> -> i've prepared gorm.app but it won't work with this current version:
>> http://gnu.ethz.ch/debian/gorm/
> 
> OK, I'll package 1.11.1/0.10.1 shortly.

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

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

thanks for the efforts.
Yours,
Gürkan

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?