kde 4.1.x backports for Lenny, best approach?

Modestas Vainius modestas at vainius.eu
Tue Jul 15 09:49:10 UTC 2008


Tuesday 15 July 2008, Peter Eisentraut rašė:
> > cons:
> >   -you need to wait until package is in testing to backport it
> That might not be a bad thing, because it ensures that the packages that
> you backport actually fit together and are synchronized and have had a
> minimal amount of public testing.
Such a big thing as kde4libs might be held out of testing due to various 
library transitions which are not important for stable release. Also, whole 
KDE usually does not migrate to testing at once, tracking which packages can 
be uploaded will cause headaches or introduce delay. It is also not a good 
idea to ship some KDE parts at newer version while other parts are still old. 
To sum up, backports.org is good for small packages but its rules, regulations 
and restrictions are inconvenient for full blown DEs like KDE.

The last but not least, when waiting for testing migration you miss "release 

> In fact, even if you choose not to use backports.org, 
> someone else might end up doing backports.org backports anyway, because they 
> prefer that infrastructure.  Such divergence can be avoided
Actually, I would welcome people to do this. backports.org rules are stict. 
Maybe even when all KDE 4.1.x packages migrate to testing, they can be re-
uploaded to backports.org from kde4.debian.net mirror. Reuploading is not a 
big deal, getting packages ready is.

Modestas Vainius <modestas at vainius.eu>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20080715/2e1b577b/attachment.pgp 

More information about the pkg-kde-talk mailing list