[Pkg-xfce-devel] Analysis of the gnome3 transitions
joss at debian.org
Fri Apr 15 09:17:06 UTC 2011
Mehdi Dogguy wrote:
>> First of all I think we should upload gtk+3.0 to unstable in the next
>> days. Together with it we can upload a lot of libraries that are
>> parallel-installable with their GTK 2.x versions.
> This happened already.
GTK3 is here, now we can start uploading libraries that depend on it.
>> 1. libnotify
> This has been requested and is tracked as #622363. As mentioned in the
> bugreport, we will try to get Xfce before (asked earlier and seems to
> simplify the transition a bit).
Yes, although libnotify 0.6 doesnt require anything and would help some
reverse dependencies already.
>> 3. devhelp
> and, anjuta-extras I guess. If everything needed is already ready in
> sid/wheezy, you can go ahead with this.
The one thing Im wondering about starting to upload GTK3 applications is
the lack of a good theme. The only theme available currently is Adwaita;
we could upload it to unstable but this means changing the default theme.
>> 4. gnome-keyring
>> It is almost a self-contained transition (gnome-keyring +
>> seahorse). However it needs to be done early because empathy
>> (involved in other transitions) will need it.
> This semi-started :/ libgnome-keyring 3.0 has been uploaded and triggered
> some bad side effects (#622556). It might be a good idea to do this one,
> if we can avoid updating seahorse-plugins ; or revert the upload.
Yeah, I think upstream f*cked up this one too. Ill see how this can be
>> 5. gedit
> This probably means not before gnome-keyring and devhelp transitions are
> over, I guess.
In any case, if we do one transition before the other, the gedit plugin
will stop working for a while. I think its a necessary evil, otherwise
were going to entangle all these transitions together.
>> 6. gnome-bluetooth
>> The only fix I can think of is to rename the source package to
>> gnome-bluetooth3 and the -dev package to
>> libgnome-bluetooth8-dev, making it conflict with
>> libgnome-bluetooth-dev. Then it will take, later, another round
>> of source uploads to change back the -dev package name.
> Sounds reasonable.
OK, will do.
>> 7. evolution
> Sounds reasonable. Does this transition need any other one mentioned
> or, is it self-contained? Just checking.
Since the source package name is changed, it is almost self-contained. The
reverse dependencies for e.g. libcamel will be rebuilt against the new
version, though, so it might block other transitions if the new package
doesnt migrate to testing soon enough.
>> 8. gnome-media + gnome-media-profiles
>> Due to the upstream split between the library and the binary, if
>> we upload gnome-media 3.x, the gtk2 library will disappear.
>> We can probably rename the source package to gnome-media3, so
>> that only the gnome-media binary is taken over, keeping
>> libgnome-media0 and -dev in the archive. Later we can rename
>> again the source package to make them disappear. (Again, cruft
>> to deal with at the end of the transitions.)
> So, affected packages here are:
> - gnome-python-desktop
> - gnomeradio
> - rhythmbox
> - sound-juicer
> (nothing build-depends on libgnome-media-profiles-dev yet).
> Bigger problem here, aiui, is gnome-python-desktop as it provides a
> and has a significant number of reverse dependencies. It depends on what
> of changes are implemented there.
> Depending on the changes required to get reverse dependencies ready, maybe
> it's not necessary to rename packages and have to deal with cruft?
Its not possible to port gnome-python-desktop; the python-mediaprofiles
binary will be removed. I dont know for gnomeradio, but I dont like the
idea to force several packages at once to migrate to GTK3 together.
>> 9. gnome-panel
> Which applets are not ported yet? (libpanel-applet2-dev has quite some
> of reverse dependencies).
Very few applets have been ported so far.
>> 10. nautilus
>> For automounting, things are a lot worse. The functionality has
>> been moved to gnome-settings-daemon and changing that would be a
>> lot of work.
>> Therefore, Iâd like to know whether the release team would
>> accept to tie this (already big) nautilus transition with the
>> big GNOME transition.
> Ideally, we prefer smaller transitions, when possible (for obvious
> So, are the changes to apply to nautilus significant? Will that take a lot
> of time to get them prepared and ready?
This is a big amount of work; Im not sure it is possible to get back
automount to work. Had it been useful, I would have volunteered to do it,
but just to make it able to transition smoothly, it looks like a lot. If
you want to have a look, these are most of the changes between 2.91.2 and
>> 11. The big GNOME transition
> Any opinion on webkit 1.3.x? Is it needed somewhere for the Gnome
Webkit, just like most GTK+ based libraries, will be parallel installable,
so there is no transition involved.
> (Reporting each as a transition bugreport and setting blockers will
Sure, will do when we have identified the inter-dependencies.
More information about the Pkg-xfce-devel