Re: status update: GNUstep library transition
Please wrap your mails at < 80 lines, trying to reply to this is moderately
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.
> 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
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.