pcp
[Top] [All Lists]

Re: pcp updates - last piece of debian packaging changes for this round

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: pcp updates - last piece of debian packaging changes for this round
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sat, 1 Mar 2014 04:19:46 -0500 (EST)
Cc: "Frank Ch. Eigler" <fche@xxxxxxxxxx>, pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <531008D6.3040908@xxxxxxxxxxxxxxxx>
References: <530F9B64.4080505@xxxxxxxxxxxxxxxx> <530FDAE6.5070308@xxxxxxxxxxxxxxxx> <506527158.18237145.1393551642685.JavaMail.zimbra@xxxxxxxxxx> <530FF605.2000809@xxxxxxxxxxxxxxxx> <1180352175.18258965.1393556591992.JavaMail.zimbra@xxxxxxxxxx> <y0m4n3kylqe.fsf@xxxxxxxx> <1156485848.18262880.1393557855271.JavaMail.zimbra@xxxxxxxxxx> <531008D6.3040908@xxxxxxxxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: TgNdQ3SyHx4+HqEiA2KNvn584JCc1A==
Thread-topic: pcp updates - last piece of debian packaging changes for this round
Hi Ken,

----- Original Message -----
> On 28/02/14 14:24, Nathan Scott wrote:
> > ----- Original Message -----
> >>>  From looking in the <microhttpd.h> header, we prefer
> >>> MHD_create_response_from_buffer over MHD_create_response_from_data
> >>> (which is still present, but marked as deprecated in the header).
> >>> Could we possibly support either API?  [...]
> >>
> >> I don't know, maybe.
> >>
> >> Or we could declare that debian oldstable is too old to build pmwebd,
> >> and give that a separate .deb .dsc file, so it doesn't even try.
> >
> > *nod* - there are many possible ways to tackle this.  Conditionally doing
> > the packaging is what was being tried but its proving problematic (and it
> > is obviously not ideal for people on older platforms), so alternatives
> > are being sought.
> 
> I was not looking to start a religious war ...

Heh, no religious wars here - just keen to explore the solution space
before we settle on one.

> 
> I don't think there is disagreement here if Nathan is OK with my
> half-reversion of the debian/control.master change to put back the build
> dependency but without an open revision range.
> 

It appears to work fine - I had some initial reservations, thinking the
control file was being generated & so we'd have another chicken-and-egg
situation, but thats not quite what it does.  We'll need to take care
that the control file we ship in the tarball matches what we want the
buildd systems to build - which it does.  Its slightly dodgey that we
may modify a checked-in file during a build (which may accidentally be
committed by someone, which we need to be vigilant about), but such is
life.

We could use this mechanism to bring the infiniband deb package back,
btw, if you're keen; it proved too problematic to enable in the buildd
builds, but we could build it locally with this control-file-append
trick.

So, yeah, its fine by me.

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>
  • Re: pcp updates - last piece of debian packaging changes for this round, Nathan Scott <=