[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

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: