etch or sid? (Was: Evince backport proposal)
> packages which enter testing have, at least, the most ovious bugs
> fixed, both regarding to debian/* and upstream. that is excately what we
Though, everything in testing was in sid earlier - so bugs, trivial or
not, get fixed faster from sid.
> apart from what i've already said above, one key point of backports.org
> is to ensure the upgrade path from sarge-backports to testing. if
> unstable backports were given, such a system would not be as easy to
> uprade as it is with testing backports.
I understand what you mean, and I now see how nicely backport makes
the current Debian release and the next one progressively closer.
But... is it really what we want? :)
I became interested in to backport because of the way it is described
on the frontpage: "the software is a little bit outdated [in
Debian]. That is where backports come in."
So I don't want to use etch in itself, I aim at latest version of a
few packages on Sarge. Etch is already less recent than the current
Ubuntu release; IMHO that's not a good source to get the latest
It is quite frustrating to experience all the delays between an
upstream release and a stable Debian package - I want to minimise such
delay, and rely on fast updates, the "release early, release often"
way, rather than on a freeze period.
Besides, during the etch freeze, backports will be frozen as
well. This policy also forbids to recompile .debs from other
Debian-based repositories, even if they integrate well in Debian.
Maybe a smooth release is worth paying such a limitation. However I
think it is already possible to seamlessly upgrade from sid
backports. It's just a matter of
Pin: release a=stable
and then something like
aptitude install `aptitude search -F %p '~i~OBackports.org'`
I already used this technique to switch from Ubuntu to Sarge.
So what is it that we want? Stick to the strict meaning of 'backport'?
Or efficiently bring the latest packages on top of the Debian stable