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