[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

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: