I agree with Gordon, it would make more sense to me to include all sources
regardless of dependency status on the box. The only time the build box
configuration should matter is for the binary packages really. In this case
I ran the build process, it compiled what it needed to for the C++ tree
without incident, I assumed it was ok...and given that it's actually a
source package why shouldn't I be able to do so?

There was a similar issue noted for 0.6
(https://issues.apache.org/jira/browse/QPID-2316) but as no one replied when
I asked people to look at it I just ended up nudging it out to 0.9 and
ensuring I had the relevant dependencies installed for RC1. It is also one
of the primary reasons I produced the alpha build a few weeks back, hoping
we wouldn't end up in the RC stage with me still needing to tinker with
dependencies to actually produce working release candidates. Oh well ;)

Is "qpid/qpid/cpp/INSTALL" up to date? I don't see a mention of 'cpg' - is
that Corosync? Alternatively does anyone have a handy list package names or
source download links for dependencies I should make sure I have installed
(Fedora 12) to fix this and any other related 'X wasn't included because Y
wasn't installed' issues for the next RC? Talking of which, I think we
should just live with it for 0.8 but fix it properly on trunk.

Thanks,
Robbie

> -----Original Message-----
> From: Gordon Sim [mailto:[email protected]]
> Sent: 10 November 2010 18:03
> To: [email protected]
> Subject: Re: failure due to missing cluster artefacts (was Re: 0.8 RC1
> available for download)
> 
> On 11/10/2010 05:41 PM, Carl Trieloff wrote:
> > On 11/10/2010 11:20 AM, Gordon Sim wrote:
> >>>
> >>> build it on a platform with deps install. that seems less error
> prone.
> >>
> >> Actually I think that ensuring the distribution is 'complete'
> >> regardless of the existence of dependencies on the platform it was
> >> built is less error prone.
> >>
> >> The question in my mind was more on whether we fix this for 0.8 or
> >> make do by regenerating with deps installed.
> >
> >
> > Ok, I'm confused. I had asumed we would want it regenerated on a
> > platform with dependencies there, so they are in the kit. I had also
> > assumed we would want the tests run on it, to make sure it works.
> i.e.
> > also test that the dependencies are correct in the making dist
> process.
> 
> Testing the dist is different from creating it. Creating it is
> inevitably one person's job (release manager's). Building and testing
> it
> can (and should) be done more widely.
> 
> In my mind the ideal is that when creating a dist, the full source for
> all possible modules are included regardless of whether the deps for
> those are available at the time of creation. That way you ease the
> burden of getting the system setup for creating the dist and leverage
> the existing systems of a wider group of testers for checking all the
> different parts. I think that is also less error prone because the
> configuration of the system on which the dist is created doesn't
> inadvertently cause important pieces to be missed. (e.g. at present we
> include the cman integration sources regardless of whether cman is
> installed when the dist is created).
> 
> However others may have a different view and/or we may wish to be
> pragmatic for 0.8. At present the RC won't build if cpg is installed
> unless you explicitly disable cpg integration.
> 
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:[email protected]



---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[email protected]

Reply via email to