What is the multimedia future for Squeeze?

[Jonas Smedegaard]

On Sun, Mar 21, 2010 at 01:53:20PM -0700, info at bandshed.net wrote:
>My question about Stable was semi-rhetorical. Having observed the 
>pattern of Debian Stable in the past (and yes I was complaining a 
>little wee bit). Now that there is a dedicated multimedia packaging 
>team I wonder if AV Linux should continue with Squeeze (less fresh 
>packages, far more core library stability) and will there be a better 
>representation of multimedia updates through down to Stable?. Or will I 
>need to continue using Testing as a base in order to continue keeping 
>pace?.
>
>Does that make more sense?

Thanks - it makes more sense to me now, yes (and perhaps if I weren't so 
jumpy/grumpy I might have understood from your first post even).

As others have mentioned already, Debian itself haven't changed: stable 
is _stable_ and only security-related updates are permitted into it 
after its release - any new features will only occur in testing, 
unstable and experimental.

backports.org is one approach to bridge the gap between stability and 
new features.  You provide another yourself, if I understood correctly.

Personally I maintain a huge pile of backported packages, some even for 
Etch (oldstable) still.  I find the governing rules of backports.org too 
relaxed, so do not participate in that.

So there are a multitude of options for mixing stable Debian with other 
parts - either testing or unstable Debian or something external to 
Debian.

What we can do here in this packaging team is to strive towards best 
possible conditions not only for a package to fullfill the requirements 
of getting into Debian unstable, but also suitable for recompilation in 
alien environments usable by various backports and sideports.

Personally I try to avoid including packaging features difficult to 
backport to oldstable, or if too much hassle then at least stable.  
Currently this means I avoid debhelper v7 because I have found newer 
releases of the debhelper package itself quite tricky to backport.

I don't mean to preach debhelper as evil here, just mention one (to me 
quite concrete[1]) example of caring about backportability when 
packaging.


Hopefully that addressed some of your concern.

Kind regards,

  - Jonas


[1] For several years I have fought to maintain a backport of the 
Perl-based LDAP admin tool CipUX for Etch, which involved backporting 
several Perl libraries that quite annoyingly have been repackaged using 
the shortform debhelper v7 that has been impossible (for me) to backport 
to Etch.  I ended up repackaging those libraries from scratch using CDBS 
- being happy that it was only Perl libraries I had to deal with like 
that, as they are luckily quite easy to package (and even easier using 
CDBS IMHO, but that's another story).

-- 
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100322/86d86b97/attachment.pgp>