Re: JACK/KDE/FLTK and other transitions
Bugs filed for the four packages which haven't been uploaded for the fltk
transition. Bugs also filed for flac, stk, and spiralsynthmodular (with
their -O3 optimization flags and m68k FTBFS).
Steve Langasek wrote (replying to me):
>> # Wine still hasn't been updated to new JACK, despite an RC bug (#321222)
>> # open for 40 days.
>> remove wine/0.0.20050628-2
>
>Why remove instead of NMUing?
It's not going to make it back into 'testing' until the wine-safe RC bugs are
resolved one way or another anyway, so I'm not sure what good NMUing would do
unless the NMUer is willing to pick a solution for that at the same time.
>> remove galan/0.3.0+beta4-1
>
>Seems to only recommend libjack rather than depend, though?
Good catch. It will have an unsatisfiable build-depends however, since it
build-depends on libjack0.80.0-dev.
>> # seq24 ties libsigc++-1.2, a complex transition, to the JACK transition.
>> remove seq24/0.6.3-1
>
>Does the libsigc++-1.2 transition become substantially simpler if we
>selectively transition other packages to gtkmm2.4/libsigc++-2.0?
Quite probably. I wouldn't want to have to push it in at the same time as the
JACK/KDE transitions in any case. Actually, seq24 is probably the one which
should be transitioned, since it's the worst tie-up; if it's transitioned
after gtkmm2.4 goes in and before libsigc++-1.2 goes in everything should be
fairly smooth I think (seq24 can then go in with JACK and KDE). Hmm. It
will have to be temporarily removed from testing in any case.
>> # Separate gtkmm2.4 transition from gtkmm2.0 transition (yeech)
>> remove gtkglextmm/1.0.1-3
>Again, why would we keep gtkmm2.0 around instead of transitioning
>everything to gtkmm2.4?
On further analysis, this package is just misbuilt, which is what confused me.
The dev package depends on gtkmm2.4, but the binary package depends on
gtkmm2.0. Hence the odd result I noticed: it depends on *both*. That can't
be right, can it? Indeed, the version in unstable is just broken; RC bug
#320577. The version in testing should stay around until there's a fixed
version in unstable, presumably.
Proceeding with the "just get rid of gtkmm2.0" idea:
* There appear to be no packages depending on any of the binary packages from
libbonobomm1.3 or libbonobouimm1.3. Perhaps the suggestion could be made to
the maintainer that these could be dropped. That maintainer is Bradley Bell
<btb@debian.org>; most of his packages are in NMU versions at the moment.
* libgtkglextmm1 is discussed above and will presumably be transitioned to
gtkmm2.4 properly soon.
This leaves the following packages depending on gtkmm2.0:
* seq24, mentioned above
* mysql-admin
* mysql-query-browser
* fireflier-client-gtk (source fireflier).
It seems entirely reasonable to transition these to gtkmm2.4, given that there
are only four of them (although nobody has suggested doing so for any of
them).
Unfortunately fireflier (like seq24) also produces a KDE package and a GTK
package, so it will cause new transition linkage if it's upgraded to use
gtkmm2.4 before transitioned gtkmm2.4 gets into testing.
I think if gtkmm2.0 can be removed, libsigc++-1.2 should be pretty easy to get
in (after a while, of course; it still has a lot of packages depending on it,
but after that it's likely none of them will be GTK, Qt, or JACK dependent,
which makes it relatively straightforward.)
--
Nathanael Nerode <neroden@twcny.rr.com>
This space intentionally left blank.
Reply to: