Re: dh_python and python policy analysis
On Sat, Aug 12, 2006 at 12:10:07PM -0500, Manoj Srivastava wrote:
> >> 3.1.3. Provides
> >>
> >> Packages with public modules and extensions should be named, or
> >> should provide, python-foo. Pure Python public modules that support
> >> all Python versions need not have a Provides field.
> > ... unless there is an application using a non-default python
> > version using this module. or else you require the application
> > depending on any indirect dependency of python-foo.
> Hmm. Two things: if application X requires my pure python
> public module (called, say, python-foo), and uses some specific
> version of python, why can't it depend on just python-foo Why do I
> have to provide pythonX.Y-foo?
Because a dependency on "python-foo" expresses the request "give me the foo
module for the current version of python". There is no guarantee that the
python-foo package installed is compatible with, or provides support for,
the pythonX.Y you're using, except if this package declares a Provides:
pythonX.Y-foo; so the depends/provides: pythonX.Y-foo needs to be there to
ensure that the app and the modules it needs aren't allowed to get out of
sync on a user's system (or in testing).
> Also, as a maintainer of python-foo, I can't know when such an
> application would be created, and we are trying to minimize
> reuploads of packages -- so either one provides all such
> pythonX.Y-foo at the get go, and reupload at every new python version
> or dropping of the old version -- or we upload every time some app is
> uploaded that may require yet abother X.y, and when we drop a version
> of Python.
Such apps would ideally be few and far between, but after thinking about it
for a while, I wasn't actually able to come up with a concrete case where
having the Provides: declared ahead of time complicates transitions more
than not having them would. For pure python modules, this still means
inconvenient sourceful reuploads when new python implementations become
available, since the Provides: can't be declared for pythonX.Y that we don't
yet know about, but fortunately those reuploads would only need to be done
on demand for modules that are actually used from scripts invoking a
non-default python interpreter.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: