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 fixed. >> 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 > 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 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 > 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? 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 > 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; 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 2.91.3. >> 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. -- Joss -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
