Re: dh_python and python policy analysis
On Sun, 13 Aug 2006 00:01:37 -0700, Steve Langasek <vorlon@debian.org> said:
> 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".
No, it does not. When a package bar depend on package baz, it
means just that-- that it requires the package baz to work. With the
policy draft that I have proposed, if it is a pure python module,
with no intrinsic restrictions on the versions of python supported,
other packages can just depend on the package, knowing that a policy
compliant package would support all available versions.
> 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:
Rubissh. You are just making up these rules, and since it
hurts, just don't make them up. If you want a pure python module
that complies with the new policy, and does not provide
pythonX.Y-foo; you know trhat you can just depend on python-foo, and
things shall work.
> 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).
And why would they get out of sync? If they are compliant,
then when a new python version is installed the module is compiled
for it -- so no matter what version of python you use, there is a
compiled .pyc file there.
>> 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.
And if you just follow the new policy, no uploads are needed
at all. The new policy wins.
manoj
--
America: born free and taxed to death.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: