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

Analysis of the gnome3 transitions

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

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:
        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

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

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
        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
              * 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
        It also requires dropping python-gnomeapplet from
        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
        I’m adding libgnomekbd, since all its rdeps are among the list
        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

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.   **

 .''`.      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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: