bzr-check-dependencies to get pqm depedencies under control

[Vincent Ladeuil]

>>>>> Max Bowsher <maxb at f2s.com> writes:

<snip/>

    > Quoting from the bug:
    >> Starting with a VM seeded with a raw hardy
    >> ubuntu-8.04.4-desktop-amd64.iso

    > This probably wasn't the best starting point. It's unlikely the
    > PQM machine would be running a desktop installation. For the
    > metapackage to be fully tested, you would want to start with a
    > minimal debootstrapped chroot, or a minimal d-i (alternate CD)
    > install.

Meh, the feedback I got from our admin was: 'pretty damn close'.

    >> Now I'd like feedback about:
    >> 
    >> - should we define another bzr-build-dependencies package excluding
    >> python-docutils ?

    > Who would be the target audience?

People wanting to run the test suite in a setup as close as possible as
the pqm one.

    >> - should we instead put these dependencies in a Build-Depends clause
    >> (but see the bug report about the catch 22) ?

    > No. Metapackages don't need any of these things to build themselves.

Ok.

    > I don't really understand what Tom means in the bug.

So the long story is that it was considered to put these dependencies
into bzr build deps.

Now, the case at point was adding python-sphinx which doesn't exist for
hardy. This requires providing a package for hardy. But before adding
this package to the bzr build deps, we need to change bzr to use it. And
landing such a change requires that python-sphinx is installed on pqm...

    >> - should I put this package in the proposed PPA or directly in the
    >> stable one (where I think it should reside permanently if only because
    >> we maintain up-to-date packages for subunit and python-testtools there
    >> already) ?

    > To proposed and immediately copy it? I think we want to keep the package
    > list in proposed and stable identical for simplicity of reporting
    > unpromoted packages.

Works For Me.

    >> - should I use another name (I chose 'check' as a reference to 'make
    >> check' and explained the intent in the package description but I
    >> wonder if people may be confused about 'bzr check') ?

    > I think we should call it bzr-pqm-dependencies.

Bah, this makes me think that it's related to the pam package or the
pam-submit plugin and also that it is specific to pqm which is not
entirely true, it helps setting up a host to be as close as possible to
pqm.

    > The name 'bzr-check-dependencies' makes me think it is a tool for
    > checking dependencies, and, it's only because it's PQM that it
    > wants Python 2.4 - the average user of 'make check' doesn't
    > necessarily want it.

<shudder>

bzr-dependencies-for-make-check-on-bzr-pqm-like-setups-including-python2.4
:-/ ?

bzr-landing-depedencies ?

    Vincent