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

Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)



On Tue, May 16, 2006 at 09:37:36AM +0200, Sebastien Bacher wrote:
> Le mardi 16 mai 2006 à 09:09 +0200, Sven Luther a écrit :
> 
> > If we decide that 2.9+ and 2.10 is the way to go for etch, then we should be
> > pro-active for this, and start experimenting, and even making them the default
> > NOW.
> 
> GTK 2.9 is GNOME 2.16 material, lot of packages Depends on GTK and
> making a "start of unstable cycle version" the default is not a good
> idea

Ok, this is what i was afraid of.

> > It is scheduled for release during may, which may or not be delayed a bit.
> > This is way this is an important point to get feedaback from the release team
> > and from the gtk-gnome team now. I am CCing them on this.
> 
> First tarball are due during may (ie: 2.9.n), not 2.10

Ah, i thought the 2.9 ones where already available.

> > If they decide to not go with 2.10 for etch, then having a random 2.9 snapshot
> > or a final 2.10 package just for us would be no worse than the current 2.0.x
> > packages that we have today.
> 
> I disagree, they is a lot of changes and new features for 2.10 and "a
> random 2.9 snapshot" is not something we are wanting to ship with a
> stable Debian

Ah, this was in the context of a gtk-dfb only package, and many of the g-i
team are arguing that a development 2.9 snapshot is preferable than the
unmaintained upstream 2.0.x stuff we are using now.

So, basically, this means we will be forced to maintain our own gtk-dfb libs
for the etch timeframe, unless there is some serious slip for the etch
release, and we have the choice of keeping the 2.0.x gtk-dfb .udebs and using
some out of the devel CVS.

Sebastien, do you know if the development 2.9 gtk packages will be uploaded to
experimental or something such ? If so, would it be meaningful to have those
packages also include the build of the .udebs, and upload to unstable a
version of those with the main .debs disabled ? PAckaging synergy of this kind
is good to reduce workload for all involved.

Friendly,

Sven Luther



Reply to: