On Wed, Mar 21, 2012 at 03:03:28PM +0100, Joachim Breitner wrote: > Hi, > > Am Mittwoch, den 21.03.2012, 14:50 +0100 schrieb Iustin Pop: > > 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. > > ok, leaf packages are less of an issue. I kinda dislike to single out > packages instead of treating all of them consistently.
I understand, and I agree with that. The question is if we have the manpower to maintain backports of all packages as a whole, instead of cherry-picking what's needed. Over the life of squeeze, I would guess we probably need just (random guess) 20% of the packages backported. > But this is Debian: If you want to invest the work, you can decide how > to do it. So you are welcome to proceed that way and I won’t hold it > against you :-) Heh :) I'm just trying to understand what is the simplest way to get N packages backported, where N is a small number. A policy/technical question now: let's say we have backports for one package (either just one or out of many). With git-buildpackage, I'd just use a bpo-squeeze branch, which would be trivial to setup. How does this work with darcs? I'm reading http://wiki.darcs.net/BestPractices and it seems to say it doesn't support _any_ kind of multiple branches in one repository? iustin -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
