On Thursday 20 April 2006 00:50, Attilio Fiandrotti wrote:
> Looking at the wiki page, i saw the transition to newer g-i libraries
> is at the first place in the meeting agenda.

Uh, that is not quite correct. What is first on the agenda is the udeb 
_dependency_ transition, which is what's needed to integrate g-i into the 
main build scripts and thus influences Beta 3.
See: http://wiki.debian.org/DebianInstaller/LibraryUdebs

Does not mean we cannot also talk about newer libraries for g-i :-)

> I've been recently experimenting with the creation of udebs from GTK
> and Cairo from CVS compiled against DFB 0.9.24 to test how much painful
> the transition would be (so far, bugs #362858 and #362860 were found).
> After some testing i found GTK 2.9 CVS snapshot dated 20060328 to
> compile and work with DFB 0.9.24 (later GTK snaphots were broken). What
> do we want to do about the GTK libraries? waiting until 2.10 is
> released or create a cvs udeb against DFB 0.9.24 ? in the case we want
> to go with the CVS solution, i can provide help and also precompiled
> i386 binaries (sadly, i failed in creating hacked udebs).

The problem remains that we cannot just dump random packages with random 
libraries into the official Debian archives. Especially if these packages 
will conflict with the current versions packaged by the official 
maintainers.
So any solution using new libraries would have to use tarballs and IMO 
that would be a step back from what we have. Also, I don't feel it would 
be right to integrate g-i into the official builds if we take libraries 
from tarballs.

For use in any officially built images, we have to wait until new upstream 
versions are released and packaged by their official packagers. Of 
course, any preparation we can do to help them quickly create the new 
udebs we will need is very useful.

> Having GTK 2.9 available for testing in the g-i would give us RTL text
> in SELECT/MULTISELECT question and would also help in finding bugs in
> the DFB backend before GTK 2.10 is released.

Yes, I agree, but given the above, I think that should remain something 
that is done privately, based on instructions from the wiki (possibly 
with the help of unofficial tarballs or packages that we could host 
somewhere on alioth).

> Also, it would be nice staring to think how to package into an udeb that
> nice "Bladr" GTK theme Luca Bruno created [1].

That is independent, unless new libraries are required for that.

Cheers,
FJP

Attachment: pgprRg2ywb2Bd.pgp
Description: PGP signature

Reply via email to