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

Re: Analysis of the gnome3 transitions

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 doesn?t 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 I?m 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. I?ll 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 it?s a necessary evil, otherwise
we?re 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
> already?
> 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
doesn?t 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
> 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?

It?s not possible to port gnome-python-desktop; the python-mediaprofiles
binary will be removed. I don?t know for gnomeradio, but I don?t 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
> number
> 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
> reasons).
> 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; I?m 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
> transition?

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
> probably
> help).

Sure, will do when we have identified the inter-dependencies.

Reply to: