On Thu, Dec 07, 2006, Josselin Mouette wrote:
> The python policy implies that if you want to build something against
> the non-default python version, you need python-foo and python2.X-dev.
> Which means in this case, a python-dev dependency should be enough. This
> would avoid pulling several interpreter versions when not needed.
Yes, so if someone wants to build against the non-default python
version, python2.X-dev will be pulled by his build-deps and, with your
proposal python-dev will be pulled by python-gtk2-dev as well, even if
it's not required. So I had the choice between:
1) depending on python-all-dev, always pulling too much, but also
protecting against missing build-deps and being generally a safe bet
which puts load on buildd (but so close to the release, I prefer
playing safely)
2) depending on python-dev, pulling too much when building against a
non-default python version, and not pulling the correct python-dev
package for the corresponding Python.h
IMO, none of the above is correct; as I stated, we should depend on
python-dev | virtual-provide-satisfied-by-all-python2.X-dev to ensure
that someone pulls some python2.X-dev or that we pull python-dev.
You prefer 2), I picked up 1) as a safe bet.
I ultimately prefer 3) (virtual provide), but I'm fine with 2):
"I think python-dev is ok as well."
BTW, you assert a Python package building against python-gobject, but
there's also the far-fetched possibility of a C program using
pygobject.h directly, or simply an user / admin building stuff locally,
without complying to the Python policy.
Anyway, I don't care, swap 1) for 2) if you like, just pick one as not
having anything is probably a RC bug.
--
Loïc Minier <[EMAIL PROTECTED]>
"I have no strong feelings one way or the other." -- Neutral President
