On Fri, Apr 16, 2004 at 12:10:00AM +0200, Jordi Mallach wrote: > As you know, the Debian GNOME team has been working on packaging > GNOME 2.6 during the last weeks. While many of us didn't count on having > them ready to opt for their inclussion in Sarge when we started, the > situation has changed now that packages are judged to be at least > unstable quality. > We'd like to hear what the release people think about attempting to get > GNOME 2.6 and GTK 2.4 into Sarge immediately. We have a number of > reasons to think that this can be done with hopefully no major > transition problems in Sid/Sarge: > - the packages have had a wide testing, and the -gtk-gnome list has been > very active with user reports of problems that have been fixed. > - the packages have been tested on !i386 thanks to Michel Dänzer's > powerpc builds, which have uncovered some build errors that have also > been fixed. > - while a few new source packages have been added, the number of sources > with new binary packages, compared to unstable, is relatively low, as > most of the splits of data files to -data/-common packages were > propagated to the GNOME 2.4 packages too. > - AFAWCT, GNOME 2.6 wouldn't affect debootstrap sarge/sid at all: one of > the transitions that have been performed in the new packages, the > switch to gnutls10 isn't an issue as gnutls10 is already in Sarge's > base system. > Before considering an upload to unstable, we would still need to > complete two outstanding TODO items: > - Debian #241706 / GNOME #138454: libeel2 btroke backwards compatibility > - Transition of GConf schemas files to /var [Aside: are gconf *schema* files actually updated? If it's a schema, I would expect it to belong under /usr. Either way, I'll be glad to have these out of my /etc.] > The first issue is probably serious and needs to be fixed. > For the second, we have a plan that should work transparently and will > allow both the new and old location for schemas work while the > transition is ongoing (something like the /usr/doc transition). There's > no problem if Sarge releases with some of the schemas files in /etc > still. This is not *required*, but very desirable. > GNOME 2.6 also fixes some bad bugs present on all versions of GNOME 2.4, > most notably the broken smb browsing. The transition to gnutls10 also > has positive side effects: it helps gdm be able to use pam_ldap > correctly, and some other GNOME software which uses gnutls to actually > work (gossip, for example). > Would the release team bless this attempt? The GNOME team thinks we can > make it. As I expressed to Jordi on IRC, because of how late in the release cycle we are, one of my requirements is that the GNOME team identify to us the minimum set of GNOME 2.6 source packages they want to release with for this effort to be worthwhile, and then ensure that the package relationships be updated to reflect this (versioned conflicts/depends) before uploading to unstable so that we don't have to delay the release because half the needed GNOME 2.6 packages got in and the other half are unreleasable. By all rights, this ought to be the norm, to preserve the releasability of testing at all times, but I know with more complicated package sets that technically support partial upgrades, package dependencies don't always reflect the opinion of the maintainers. I've offered to help identify the missing package relationships needed to enforce the GNOME team's release expectations. I would also like to see some analysis of how GNOME 2.6 in unstable will affect other non-GNOME packages. For instance, if GNOME 2.6 requires a new version of GTK+ as well, will this require a transition for other GTK+-using packages? If GTK+ 2.4 has the same soname as GTK+ 2.2 (the package name in unstable suggests this is so), can GTK+ 2.4 safely be allowed into testing, or will other GTK+-using packages have to wait for all of GNOME 2.6 to be ready before they can be updated in testing? (Note that if the answer is that it can't be safely allowed into testing in advance of GNOME 2.6, the package name in experimental is almost certainly wrong.) Finally, are there any bugs you currently know of affecting GNOME 2.4 in testing that you would not be willing to live with through a 2-year release cycle if GNOME 2.6 didn't make the cut? Anthony and Colin may have other concerns; I'll let them speak for themselves. For my own part, if you can address the above, I don't see any reason why GNOME 2.6 can't be allowed into unstable. Regards, -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature