Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tue, May 16, 2006 at 10:58:52AM +0200, Sebastien Bacher wrote:
> Le mardi 16 mai 2006 à 10:23 +0200, Sven Luther a écrit :
> > Ok, but if someone else would be packaging those to produce .udebs, you have
> > no particular objection to uploading .debs to experimental at the same time ?
> Are you saying you want to hijack GTK now?
I am saying, that upto now, the d-i team has been maintaining a set of gtk-dfb
2.0.x package. Since then, we worked with the directfb upstream folk to get
gtk-dfb integrated in the main gtk pckages, and this has been happening for
the current devel tree.
The question at hand is if it would be more meaningfull to keep working with
the 2.0.x libraries, knowing we are alone in maintaining them, and they have
some known bugs which will not be fixed, or go with the development 2.9+ ones.
This is for the d-i .udebs and related development files, not the main gtk
packages. Having those gtk-dfb libraries being built from the main gtk
packages would be good, which is why i asked you, but as i feared, it will not
be in time for etch, but it is definitively something that should be kept in
ming for gtk 2.10 and etch+1.
So, my (akwardly asked maybe) question was, if it would make sense to share
the work on the 2.9+ packages needed for .udebs (if we go that way), with the
gtk/gnome team, in order that this work can be more easily reused by the
gtk/gnome team once you are ready to go with 2.10, and maybe also benefit from
the occasional hiint or advice.
I am not familiar with the gtk packaging though, and maybe it is best if Eddy
takes over this discussion, given the animosity between Frans and me, but it
would be nice to have feedback on these issues. More clearly, there are two
1) you did comment on gtk 2.9+ for etch as the main gtk package, but does
this advice also hold in a 2.0.x vs 2.9+ d-i gtk-dfb scenario ?
2) do you have any comment and advice concerning re-use of the gtk packaging
infrastructure to build the needed .udebs and -dev libraries, in such a way
that they would not conflict with the remaining gtk libraries.