Re: Feasibility of backports?
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
Reply to: