[Debian GNUstep maintainers] GNUstep libraries soname bump

[Hubert Chathi]

On Sun, 8 Mar 2009 13:04:29 +0100 Adeodato Simó <dato at net.com.org.es>
wrote:

> Okay, let's see. From that URL, I get that the set of disappeared
> binaries (which is what matters to us) is:
> 
>     gnustep-back0.14
>     gnustep-back0.14-art
>     gnustep-back0.14-cairo
>     libgnustep-gui0.14
>     libgnustep-base1.16
>     libgnustep-base1.16-libffi
> 
> Please correct me if I've left anything out, it is very important for
> transition planning.

That looks about right (plus some -dbg packages).  Nothing depends on
libgnustep-base1.16-libffi, or on gnustep-back0.14-* (except for
gnustep-back0.14 itself).

> This transition is tied to the ffmpeg-debian transition via
> lynkeos.app. I think it's a pity you can't start working on an
> otherwise very isolated transition because of that, but at the same
> time I don't want to make ffmpeg wait on GNUstep.

Agreed.

> So, what I'm going to propose, is that you go forward with this
> transition, but only once lynkeos.app has been rebuilt against the new
> ffmpeg in all architectures. At the moment, it is failing everywhere
> because of #487641.
> 
> Once a fix for #487641 is in unstable, and built in all architectures,
> you may go forward with this transition. However, when scheduling
> Bin-NMUs, I will skip lynkeos.app until the ffmpeg transition is done
> (as to not tie them together). However, and as to not leave
> lynkeos.app broken in unstable too long, if the ffmpeg transition
> looks far from ready when scheduling GNUstep Bin-NMUs, I will not
> skip it, and solve it some other way.

Sounds good.

> Does this sound acceptable to you? Please do not upload new GNUstep
> components to unstable until we've cleared up together that
> lynkeos.app is fixed everywhere. Uploading to experimental is fine,
> of course, and that will allow you clearing NEW while lynkeos.app
> sorts itself out.

I have uploded gnustep-base, -gui, and -back to experimental for now.  I
have uploaded gnustep-make to unstable because it doesn't
introduce/remove any packages.

-- 
Hubert Chathi <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