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

Re: ping for gtk+extra2 removal - implications for libgtkada2 and gpsim



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: pgp3No71ouG54.pgp
Description: PGP signature


Reply to: