Re: dh_python and python policy analysis
On Sun, Aug 13, 2006 at 03:32:27AM -0500, Manoj Srivastava wrote:
> 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.
Then what do you name a package that is a pure python module that *DOES*
have intrinsic restrictions on the version of python supported? You are
wrong to assume that a pure python module will automatically support all
available versions of python -- if all python versions were completely
backwards- and forwards-compatible with one another, there would be no
reason in the first place to *have* multiple versions of them in the
archive.
The reality is that there *are* language differences with each
implementation of python, and a pure python module may *not* work with any
given implementation of python available in the archive, and we need a way
to express such dependencies that guards users against package relationships
being satisfied by broken combinations.
> > 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.
What hurts is your ignorance of design requirements that were discussed at
length at the DebConf python BoF.
> 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.
No, only packages that invoke /usr/bin/python as interpreter can do this.
Packages that invoke /usr/bin/pythonX.Y can't possibly have any forward
guarantee that python-foo will provide a working interface for the version
of pythonX.Y they have installed.
> > 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.
Python decorators are a language feature available only in python 2.4 and
above. Given a module foo version 1.0 which does not use decorators, a
module foo version 2.0 which does, and a package bar which invokes
/usr/bin/python2.3 and depends on "python2.3, python-foo", how do you
protect against installing python-foo 2.0 and breaking bar? It doesn't
matter a bit whether the .pyc is in the python2.3 search path when the
module in question isn't compatible with that version of the language.
--
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: