Hey, I have been thinking what is the best way to do the 4.1.x backports to Lenny. Basically, I see 2 options: a) Use backports.org, i do not like this too much because: cons: -you need to wait until package is in testing to backport it -packages go to NEW until they are hand approved -users will fear to push more stuff than just KDE 4.1.x pros: it has support for most used archs, and it is autobuilt. b) Search for a mirror space where optionally (but very welcome) reprepo can be used. The domain kde4.debian.net could be pointed there. cons: -need to get mirroring somewhere. Debian machines are sometimes used for this, but i do not think it is a good idea given the sizes of the KDE packages. -only able to upload packages for amd64/i386, no powerpc. pros: - dos not have any of the cons of a) Suggestions? Ana
Am Montag, 14. Juli 2008 schrieb Ana Guerrero:> a) Use backports.org, i do not like this too much because: > > cons: > -you need to wait until package is in testing to backport itThat 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.> -packages go to NEW until they are hand approvedYes, but that is quite fast in my experience.> -users will fear to push more stuff than just KDE 4.1.xBackports are not automatically installed, so this fear is irrational (albeit not unreasonable). A lot of users use backports.org successfully. Which brings me to the main point: Many users are familiar with backports.org, and it has a semi-official status in the Debian community. So why not build on that? 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.
Hi, 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 hype".> 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 avoidedActually, 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
Hi, Monday 14 July 2008, Ana Guerrero ra??:> a) Use backports.org, i do not like this too much because: > [snip] > pros: it has support for most used archs, and it is autobuilt.- People would be able to backport plasmoids and upload them to backports.org However, KDE 4.1.x term is pretty short and this point might not be very important.> b) Search for a mirror space where optionally (but very welcome) reprepo > can be used. The domain kde4.debian.net could be pointed there.I would also prefer this approach. Actually, a mixed one. More bleeding edge backports at kde4.debian.net and once they all meet backports.org requirements (i.e. testing migration), they can be re-uploaded to backports.org> cons: > [snip] > -only able to upload packages for amd64/i386, no powerpc.Initially, they can be amd64/i386. Maybe someone will volunteer to build powerpc packages and when packages meet backports.org criteria, they can be reuploaded there to benefit from backports.org pros. -- 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/990d7759/attachment.pgp