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.
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.
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.
3. devhelp
It is almost a self-contained transition (devhelp + anjuta).
AFAICT it can be done at any time.
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.
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.
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.
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.
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.)
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.
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.
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. If you have read the whole mail, congratulations.
** TL;DR: I’d like to know when we can schedule all of these, and **
** whether the migration scenarios I have evoked are realistic. **
Thanks,
--
.''`. Josselin Mouette
: :' :
`. `' “If you behave this way because you are blackmailed by someone,
`- […] I will see what I can do for you.” -- Jörg Schilling
signature.asc
Description: This is a digitally signed message part
