Re: Feasibility of backports?

2012-03-23 Thread David Fox
On Thu, Dec 8, 2011 at 1:15 PM, Joachim Breitner nome...@debian.org wrote: Hi, Am Donnerstag, den 08.12.2011, 20:51 +0100 schrieb Iustin Pop: I'm asking more from the point of view of upstream, rather than Debian packaging. I presume that due to the ghc6→ghc migration, doing backports for a

Re: Feasibility of backports?

2012-03-23 Thread Joachim Breitner
Hi, Am Donnerstag, den 22.03.2012, 14:49 +0100 schrieb Iustin Pop: Just to clarify something, since we talk about debcheckout: should a backport, since it uses a different VCS, update the Vcs-* entries? They are not critical, but I think they should be. I think I did not do it for

Re: Feasibility of backports?

2012-03-22 Thread Joachim Breitner
Hi, Am Mittwoch, den 21.03.2012, 17:01 +0100 schrieb Iustin Pop: 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

Re: Feasibility of backports?

2012-03-22 Thread Iustin Pop
On Thu, Mar 22, 2012 at 02:35:41PM +0100, Joachim Breitner wrote: Hi, Am Donnerstag, den 22.03.2012, 12:38 +0100 schrieb Iustin Pop: 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

Re: Feasibility of backports?

2012-03-21 Thread Iustin Pop
On Thu, Dec 08, 2011 at 10:15:48PM +0100, Joachim Breitner wrote: Hi, Am Donnerstag, den 08.12.2011, 20:51 +0100 schrieb Iustin Pop: I'm asking more from the point of view of upstream, rather than Debian packaging. I presume that due to the ghc6→ghc migration, doing backports for a few

Re: Feasibility of backports?

2012-03-21 Thread Joachim Breitner
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

Re: Feasibility of backports?

2012-03-21 Thread 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

Re: Feasibility of backports?

2012-03-21 Thread Iustin Pop
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

Re: Feasibility of backports?

2012-03-21 Thread Joachim Breitner
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

Feasibility of backports?

2011-12-08 Thread Iustin Pop
Hi all, I'm asking more from the point of view of upstream, rather than Debian packaging. I presume that due to the ghc6→ghc migration, doing backports for a few simpler packages (not yesod or such) is still not an easy task, right? A good example that I'm thinking about is aeson; it has about

Re: Feasibility of backports?

2011-12-08 Thread Joey Hess
Joachim Breitner wrote: my thought is that if we do backports, then we should backport the complete set of haskell packages, including ghc, so the ghc6→ghc migration should not be a problem; we just do it in backports as well. So it is basically a problem of rebuilding everything, i.e. of