Re: New Gnash 0.8.5 actually works!
-----BEGIN PGP SIGNED MESSAGE-----
On Mon, Apr 13, 2009 at 11:51:48PM +0200, Andreas Tille wrote:
> On Mon, 13 Apr 2009, Jonas Smedegaard wrote:
>> Gnash 0.8.5 was released for Debian Sid the other day, and works
>> nicely for me - I have now watched a youtube video online for the
>> first time ever (I've used clive till now). Other flash sites, like
>> the british mikmik webdesign website that interests my girlfriend,
>> works too.
> That's really good news.
>> I have backportet the new Gnash to Lenny for i386 and amd64. Add to
>> /etc/apt/sources.lst the line below, if you want it:
>> deb http://debian.jones.dk/ lenny gnash
> Any reason not to use backports.org?
I do not trust backports.org. So I won't encourage others to trust it
either, by publishing my work there.
backports.org "will run without new libraries (wherever it is possible)"
but in many cases, especially with larger projects, that either means
massaging the package so that in reality it becomes a slightly different
package, there is cheating involved. I call it cheating because there
is no structure for handling the needs for chains of backports - each
backported package is assumed being possible to compile against old
This concrete case is a good example: Debian recently switched to a
major new release of libtool, and shortly after that the new Gnash was
released for Debian. My packporting effort revealed that the package
turns out to depend on that new libtool, and I needed to also backport
the newer libtool. Alternatively I could probably have reworked the
packaging to force-regenerate the libtool part - but I would risk
breaking something in such invasive change.
What I did was compile libtool 2.x in a clean Lenny environment, and
afterwards compile gnash 0.8.5 in an _almost_ clean Lenny environment -
poisened only by that backportet libtool. Oh, and I also tightened
gnash build-dependencies on libtool and libltdl to force use that newer
The difference between my backports and those at backports.org is that I
keep track of the chains of poisening during chained backports. If
later a bug is revealed in part of a chain, I can easily see what needs
rebuilding and can redo same chains again using newer/corrected parts.
Backports.org is not transparent about this need for hacking not only
each single package but also sometimes their dependencies.
Thanks for asking,
 See http://bugs.debian.org/523902
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
-----END PGP SIGNATURE-----