[Pkg-xfce-devel] Analysis of the gnome3 transitions
Mehdi Dogguy
mehdi at dogguy.org
Wed Apr 13 13:03:08 UTC 2011
Sorry for the late reply, and thanks for this detailed analysis. It's very
helpful!
On 0, Josselin Mouette <joss at debian.org> wrote:
> Hi again,
>
> not all modules are ready, but I’ve had a closer look at what the GNOME
> 3 library transitions imply and how we can deal with their testing
> migrations in a sane way.
>
> 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. I don’t expect these
> libraries to cause any trouble: their source packages were renamed, we
> will just rename them back to remove the gtk2 version when all reverse
> dependencies are fixed. Some of them have a -common package that was not
> renamed (e.g. libgweather) but the new one should work with both
> versions.
>
This happened already.
> Once this is done, we will need slots to organize all transitions that
> depend on it, and that makes quite a number of them. I’m not sure the
> list is complete, but it should be a good start. I’ll send another mail
> if I discover more.
>
> 1. libnotify
> Once gtk3 is here, we can upload libnotify 0.6. This version is
> binary-compatible with 0.5.0, except that it doesn’t depend on a
> specific version of GTK+. This is the easy part, but it can be
> skipped, since anyway we need a transition:
> libnotify1→libnotify4.
>
> Many packages will not build without source changes since
> functions were removed, however the source changes are
> independent from the GTK+ version. So we only need to ensure
> this transition is handled independently from the rest - and
> before the rest, since it is a prerequisite for most of the
> others.
>
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).
> 2. libchamplain
> A first transition from 0.4 to 0.8 (still gtk2), with both
> source package and binary packages changed, will first be
> conducted in unstable. Then 0.10 (which is gtk3) will be handled
> the same.
>
> I don’t expect this package to cause trouble, but it will need
> to be kept on the radar; depending on the state of this
> transition we might have to temporarily disable libchamplain
> support in some reverse dependencies.
>
This started already. libchamplain-0.8 got accepted yesterday and is
already built almost everywhere (except on mips/mipsel which are lagging
behind). It's tracked as #618344.
> 3. devhelp
> It is almost a self-contained transition (devhelp + anjuta).
> AFAICT it can be done at any time.
>
and, anjuta-extras I guess. If everything needed is already ready in
sid/wheezy, you can go ahead with this.
> 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.
>
> I think we can avoid updating seahorse-plugins at the same time;
> if we cannot, we’ll want to disable some of the plugins to avoid
> tying it to gedit and/or nautilus.
>
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.
> 5. gedit
> This transition should be contained within gedit and the
> packages providing plugins.
>
> There might be breakage with packages providing extra gedit
> plugins together with other functionality, but I prefer to have
> them not working for a while rather than tying gedit to a larger
> transition.
>
Just as a reminder, packages providing plugins for gedit (other than gedit
itself) are:
- devhelp
- gedit-latex-plugin
- gedit-plugins
- gedit-r-plugin
- rabbitvcs
- seahorse-plugins
- valatoys
- gedit-valencia-plugin
This probably means not before gnome-keyring and devhelp transitions are
over, I guess. But, that shouldn't be an issue since they are on their way.
So, you still have time to ask maintainers of those packaeges to test with
gedit-dev from experimental. Did you ask?
> 6. gnome-bluetooth
> This one is really fucked up. Upstream didn’t change the API
> version with the switch to gtk3, in violation of the GNOME
> guidelines.
>
> 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.
> 7. evolution
> A big transition is expected for evolution. It involves, as
> usual, evolution{-data-server,,-exchange,-rss}. gtkhtml has a
> new source package (gtkhtml4.0) which is parallel-installable.
>
> Binary rebuilds are needed for all packages depending on:
> libcamel, libebackend, libedata-book, libedata-cal.
>
> The API for libedataserverui has changed, and since it depends
> on gtk3 now, we should really provide a way to have both
> versions available at the same time. Here is what I propose:
> * The new version for the evolution-data-server source
> package is named evolution-data-server3.
> * The binary package names are not changed; implying
> evolution-data-server and -common will be the 3.0
> version. However libraries will be
> parallel-installable.
> * We let both versions into testing.
> * Once nothing remains of the old libedataserverui’s rdeps
> (and that means after the end of other GNOME
> transitions), we remove the old versions from unstable
> by re-uploading e-d-s 3.0 with the old source name.
>
Sounds reasonable. Does this transition need any other one mentioned already?
or, is it self-contained? Just checking.
> 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 library
and has a significant number of reverse dependencies. It depends on what kind
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?
> 9. gnome-panel
> Theoretically, this one should be done with the big gnome3
> transition (see below). However it sounds insane to couple it,
> since it breaks all existing panel applets.
>
> Updating it without updating the rest of GNOME implies making
> sure that it can be a drop-in replacement for gnome-panel 2.
> First of all the applet setup will be ditched upon upgrade, but
> I don’t see this as a real problem. However interaction with the
> old gnome-session (especially with saved sessions) could be.
> This implies a lot of testing if we want to keep this transition
> separate.
>
> It also requires dropping python-gnomeapplet from
> gnome-python-desktop.
>
> I can think of two approaches here.
> * I’d prefer to get entirely rid of libpanel-applet2-0 and
> all applets that depend on it. We migrate the new panel
> to testing, remove them all and re-add them if their
> upstreams port them to the new API.
> * We can keep the old API in a different source package
> that would remain around for some time. However it would
> mean users could install applets that don’t actually
> work with the panel, but only with e.g. Xfce. It’s less
> breakage but more confusion.
> I’d appreciate the input of the release team on this topic.
>
The second approach also means same number of applets for Xfce users.
So, maybe an input from Xfce maintainers would be helpful here.
I personally don't have a preference. We can choose the first approach
if Xfce maintainers agree too. (Adding them in CC:). Will Xfce 4.8 provide
a new implementation for deperecated applets?, or its own new set of applets?
Which applets are not ported yet? (libpanel-applet2-dev has quite some number
of reverse dependencies).
> 10. nautilus
> This version of nautilus will break all nautilus extensions,
> which need to be ported to gtk 3. So it will be tied to brasero,
> file-roller, evince, tracker, totem, gnome-disk-utility,
> gnome-user-share. For some of these modules it might make sense
> to drop nautilus support temporarily, but for things like
> gnome-disk-utility this is simply unrealistic.
>
> The desktop icons are no longer drawn by default in nautilus
> 3.0. The default could be temporarily reverted until the big
> GNOME transition but currently it is unusable and requires
> fixing. I also think compatibility with older gnome-session (and
> saved sessions) will need fixing.
>
> 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 reasons).
So, are the changes to apply to nautilus significant? Will that take a lot
of time to get them prepared and ready?
> 11. The big GNOME transition
> It implies at least the following packages that need to migrate
> together.
> gdm3
> gnome-control-center
> gnome-media
> gnome-power-manager
> gnome-screensaver
> gnome-session
> gnome-settings-daemon
> gnome-shell
> I’m adding libgnomekbd, since all its rdeps are among the list
> anyway.
>
> If nautilus has to be added (and it has unless we spend a lot of
> time on nautilus changes that will have to be reverted later),
> this makes the transition much bigger.
>
> The same holds for gnome-panel but it should be more easily
> avoidable.
>
> If you know of other libraries that will be involved, please speak up now.
>
Any opinion on webkit 1.3.x? Is it needed somewhere for the Gnome transition?
I'm thinking about epiphany, anjuta, devhelp, empathy, yelp... but you
didn't mention them; so maybe not required to happen with the big Gnome
transition.
> If you have read the whole mail, congratulations.
>
\o/ May I have a present now? :p
> ** TL;DR: I’d like to know when we can schedule all of these **
>
So, to summarize:
- libchamplain already started.
- We will try to get Xfce in before starting libnotify.
- gnome-keyring has some bits in already.
- devhelp seems okay to start now (as it seems really self-contained and
small).
- gnome-bluetooth can be started too, if the plan is to get the new library in
testing first, then get the other changes done (so that it doesn't conflict
with other transitions).
- the rest... waiting for more details asked in this mail (and probably some
other transitions to finish).
There are also a few transitions waiting already (perl, ocaml, eglibc, ...).
So, this probably needs more checking before being able to start the big
Gnome transition.
So, I can't say exactly when we will be able to start the rest, but I'll keep
you updated and we will try to run as much transitions as possible in parallel,
when possible.
(Reporting each as a transition bugreport and setting blockers will probably
help).
Regards,
--
Mehdi Dogguy
More information about the Pkg-xfce-devel
mailing list