[Debian GNUstep maintainers] Re: status update: GNUstep library transition

[Hubert Chan]

On 2006-10-21 02:11:43 -0400 Steve Langasek <vorlon at debian.org> wrote:

> Hubert,
> 
> Please wrap your mails at < 80 lines, trying to reply to this is moderately
> painful :/

Sorry.  GNUMail used to automatically wrap lines, and set the
content type as format=flowed (I'm pretty sure of this, because
I used to have occasional problems talking to control at bugs.d.o),
but that seems to have changed at some point, and I didn't notice.
I'll try to remember to wrap manually until that can be changed back.

> On Sat, Oct 14, 2006 at 12:07:01PM -0400, Hubert Chan wrote:
>> Currently, gnustep-core-devel, from meta-gnustep, depends on
>> libgnustep-base1.11-dbg and libgnustep-gui0.10-dbg, which will no longer
>> be available with the new GNUstep libraries.  Which I think would prevent
>> the migration to testing.
> 
> Yes, it absolutely would have if Andi hadn't pushed it in.  My question was,
> why would you rather release with newer individual packages without any
> metapackages for upgrade support, than release with an older GNUstep that
> was actually properly installable?  Because that's what the request to
> remove meta-gnustep amounted to, and that's something I would prefer to
> avoid in the future.

OK, sorry I misunderstood the question.  The plan was to remove
meta-gnustep for now, and then push it back in later, once everything
was updated, and the packages in NEW were processed.  Looking back,
that might not have the best plan.  Of course, I also expected that
the packages that are still stuck in NEW right now would have been
processed by now...  (It's been about 7 weeks already?)

>> P.P.S. Steve, could I request a freeze exception for meta-gnustep: in the
>> (seemingly likely) case that not all the GNUstep packages get through NEW
>> before the freeze, would you (or aba) allow Gürkan to upload a new
>> meta-gnustep that will depend only on the packages that made it into etch?
>> I understand that he has been delaying an upload of meta-gnustep, so that
>> he can include the stuff that's currently stuck in NEW, and not have to
>> make too many uploads, but if it's too late for those to be included in
>> etch, it would be good to at least have a meta-gnustep in etch that
>> depends on the packages that do make it in.
> 
> For an arch: all package such as this, I would greatly prefer more frequent,
> incremental uploads instead of waiting for packages to clear NEW that may or
> may not be approved in time for the release.  Since the uninstallability of
> gnustep-core-devel is an RC bug, a fix would qualify for a freeze exception,
> but I would certainly be much happier to see this fixed sooner rather than
> later.

OK, thanks for letting us know.

Gürkan, please take note of this and be prepared to make frequent
updates as packages clear NEW.  I can sponsor these uploads for you,
so that you don't have to bug daniel as much.  Or, if you want,
I can do NMUs for meta-gnustep.

-- 
Hubert Chan <uhoreg at debian.org> -- Jabber: hubert at uhoreg.ca
PGP/GnuPG key: 1024D/124B61FA         http://www.uhoreg.ca/
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA