On Mon, 29 Jun 2009 22:56:30 +0200 Ludovic Brenta <ludovic@ludovic-brenta.org> wrote: > Neil Williams <codehelp@debian.org> writes: > > OK, there is a bug report already asking for libgtkada to not > > build-depend on gtk+extra2 (#534872) but I don't see how using an > > embedded copy is going to solve the problem. > > > > The embedded copy is just going to break in precisely the same way > > as the copy packaged as gtk+extra2. There hasn't been an upstream > > release for years, so it is the same code and will FTFS in > > precisely the same way. > > Right; I realized that while thinking a bit about the issue earlier > today. Then I went to gtk.org and it seems that GTK+3 is still many > months away from release. > > Is there a published roadmap for when GTK+2 is removed from Debian? That isn't the problem - things will break in gtk-extra2 long before GTK+2.0 is removed and there is *nobody* to fix the breakage. > Because this is really the crux of the problem; as long as GTK+2 is in > Debian, it is possible to build gtk+extra2 (be it bundled with > libgtkada2 or not) against it. Sadly, that isn't true. gtk+extra2 will FTBFS as soon as the functions that will be removed in GTK+3.0 become deprecated in GTK+2.0. GTK+2.0 doesn't have to be removed from Debian for gtk+extra2 to break. Yes, that isn't how things *should* work and it isn't how other packages *do* work but gtkextra has been dead upstream for such a long time that bitrot has all but ensured that this will be the result. gtk-extra2 is *already* too much work to maintain *in Debian* due to these problems. Even fixing gtk-extra2 to be able to handle the transition correctly is too much work because nobody is apparently interested, least of all me. i.e. gtk-extra2 is *already* sub-standard for Debian IMHO and I don't think it should persist into Squeeze. Yes these are (currently unfiled) bugs in gtkextra, yes these things don't happen to most packages but no, nobody is going to fix those bugs so the builds will fail. If any such bugs are filed, I'll move straight to seeking removal. Even if none are filed before DebConf9, I'll be seeking removal at that time. My only proposal to fix these bugs is to RM: gtk-extra2 before it gets forcibly removed. All I'm saying here is that none of the issues that will require this *premature* removal of gtk-extra2 from Debian appear to have been fixed in the embedded copy in gtkada and therefore falling back to that copy will not protect gtkada from the problems that will cause the premature removal of gtk-extra2 itself. If you want to fix these bugs in gtkada, you might as well consider taking over maintenance of gtk-extra2 and fix them there - by doing a new upstream release and probably a SONAME transition. It's too much work for me. > If you could point me to such a roadmap, I could then try to persuade > upstream to reimplement some of the GtkAda-specific widgets with GTK+3 > instead of gtk+extra2. I don't think they'd be willing to invest > effort without a definitive roadmap, especially for as long as most > of their customers continue running GTK+2. I don't think the gtkada upstream have any other option - but you will need to be very careful about function calls in gtk-extra2 that are or will be deprecated. It is slightly easier with the embedded copy because you control which functions are relevant. The issue with gtk-extra2 as a library package is that the changes required are too invasive and too widespread to be manageable without becoming the upstream team and I refuse to do that. However, even with an embedded copy of gtk-extra in gtkada, you will *NOT* be able to properly transition the rest of the package to GTK+3.0 as the gtkextra stuff will break (spectacularly) when you try to port the rest of the package to GTK3.0. Complicating the GTK3.0 transition is not my idea of helping Debian (or gtkada for that matter). This is what is preventing me from completing the port of quicklist from gtk1.2 to gtk2.0 - Quicklist no longer depends on gtk1.2 but only at the cost of removing large chunks of code and therefore functionality. The bitrot in gtkextra just makes it much more difficult than it should be to reimplement that functionality in quicklist and then the very real prospect that quicklist will never make it to GTK3.0 without also rewriting large proportions of gtkextra2 makes the whole thing unfeasible. *There will be no gtkextra for GTK3.0* and reimplementing gtk-extra2 widgets in GTK+3.0 is an immense task because gtk-extra2 is barely out of transition from gtk1.2 - it uses plenty of widgets that already have better replacements in GTK+2.0. My advice would be to drop gtk-extra2 support in gtkada *NOW* and then start the long road to GTK+3.0 compatibility once the gtkextra cruft has been removed. AFAICT, gtkada cannot proceed with any gtk-extra2 support if it ever wants to be compatible with GTK+3.0. > I am aware of [1] but this seems not to be a definite plan (rather, it > points in a general direction) and the timeline is still vague. Is > there something more solid? Also, this post seems to imply that GTK+3 > will replace GTK+2 in Debian but perhaps there could be a transition > period during which the two coexist? There will be a transition period for GTK, as always. We're only just getting rid of gtk1.2 after all. There will be no transition for gtk-extra2 other than this current period of discussion pending removal. Sadly, the problems with gtk-extra2 cannot be put off until the *end* of the transition, they will cause breakage at the very start and IMHO the problems are already too large to be justifiable. The single biggest reason why gtkextra is going to be so badly behaved is that it has been neglected for so long, upstream. If you want to fix gtk-extra2, be my guest. You are welcome to take over maintenance of gtk-extra2 at any time before DebConf9, don't wait for me to orphan it - I'm only seeking removal. As above, you *might* be able to insulate against some of the problems within a private embedded copy of gtk-extra2 but you (and your upstream) are on your own with that one. YMMV but my perspective is that this is a lost cause and a whole world of unnecessary pain. If you like lost causes, please don't look to me for help. :-( -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpiGlkFdbol9.pgp
Description: PGP signature