On Wed, Mar 21, 2012 at 02:41:28PM +0100, Joachim Breitner wrote: > Hi, > > Am Mittwoch, den 21.03.2012, 14:29 +0100 schrieb Iustin Pop: > > On Wed, Mar 21, 2012 at 01:24:40PM +0100, Joachim Breitner wrote: > > > Hi, > > > > > > Am Mittwoch, den 21.03.2012, 13:07 +0100 schrieb Iustin Pop: > > > > So, I'm again looking at this problem, as my work project has started > > > > depending on newer versions of a few libraries than are available in > > > > stable, so if we actually want to provide a backport to squeeze, we need > > > > to solve that problem too. > > > > > > > > I'm a bit split about the entire set as opposed to 5 libs. On one hand, > > > > I understand the nicety about nice upgrade paths, but on the other hand > > > > I'm not sure how big the effort is for the entire rebuild (as opposed > > > > to, again, just ~5 libs). > > > > > > > > Thoughts? Do you think it's feasible and "cheap" enough to do the entire > > > > platform backport? > > > > > > for a local backport, just rebuilding 5 libs is of course the right > > > thing to do. But I’m reluctant to start backporting individual libs for > > > squeeze-backports; that would be confusing to the users and also tricky > > > when depending packages need to be rebuild (I am not sure whether our > > > infrastructure handles that). > > > > Just for the record, I'm talking indeed about squeeze-backports, not a > > local backport. > > > > So, it means I have to look into the entire thing. Hrmm… I guess > > starting to see just whether ghc 7.4 can be backported is the first step > > (once current transition is over). > > this will take a while; the buildds are slow, there is the unresolved > issue with darcs (http://bugs.darcs.net/issue2095), there are some > unresolved build issues and so on. I guess you can start earlier :-) > > Also, you should first find out if the backports team actually wants 430 > backported packages that all need to be build on all arches... I think > an unofficial repository (with only amd64), just to demonstrate > feasibility, would be good to start with.
Yes, this is exactly the kind of potential issues that make me dislike the "entire world" backports choice. Just to understand better: why do you think a backport for (e.g.) libghc6-hslogger-dev is confusing for users? It's a leaf package, so no rebuild issues, etc. For me at least, that seems a trivial thing, whereas even only ghc (7.4) backport is daunting. iustin -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
