Le jeu 27 juillet 2006 23:20, Manoj Srivastava a écrit :
> On Thu, 27 Jul 2006 14:15:47 -0500, Joe Wreschnig
<piman@sacredchao.net> said:
> > Your confusion is due to an incorrect distinction. .py and .so
> > files are both modules; .so files are "extension modules" and .py
> > files are "pure Python modules". When the word "module" is used
> > alone it always refers to both.
>
> Then please explain section 2.2:
> "Public modules should be packaged with a name of python-foo, where
> foo is the name of the module. <snip> This requirement also applies
> to extension modules; binaries for all the supported Python
> versions should be included in a single package. "
>
> The wording implies that Public modules are distinct from
> extension modules (since something stated for public modules
> also applies to extension modules. Policy otherwise states public vs
> private and pure modules vs extension modules are orthogonal, so
> there is an inconsistency here.
public modules are modules that live
in /usr/{lib,share}/python$VERSION/site-packages/ and that anybody
can 'import' in a python program
whereas python private modules/extensions are modules that are used
internally by a program, but that it does not intend to share with
others. it's completely orthogonal to beeing pure python or a C
extension.
wording in the python folks is often module (like in pure python module)
vs. extension (like C extension). I suppose it's sometimes hard to
write a policy with a wording a bit different of what is often used.
*I* personnaly prefer module/extension terminology, as it's nearer to
what it is. a module is implicitely written in the language, whereas an
extension cannot, hence is written as an C library. but this is
nitpicking.
> > Because then applications using the default python
> > (/usr/bin/python) can access it, and that will be true for versions
> > beyond 2.4. The versioned names are not appropriate for packages
> > using the default version.
>
> Why do my packages need to change the dependencies, then?
> Because when the default changes to 2.5, the dependency would have
> to change yet again, for no changes in the package itself.
yes but the package would only need a rebuild (aka binNMU) which is the
whole point of the policy: make the python transition be a big run of
binNMU for arch:any packages (as per definition, arch:all packages are
not binNMUable)
and if you use dh_* thingies, it achieves that. I suppose it's also
doable without them though.
> Oh, I see. Say, there is an extension that implements a very
> standard API for framework bar, which is packaged in package
> bar. If this extension modules is used by a non-version-specific
> script, the script can just import module foo, and not care that it
> lives in a version specific dir.
>
> Expanding on that thought, suppose I have python-foo version
> 1.0 that has been compiled with python 2.3. If the script uses
> /usr/bin/python2.4, it won't be able to import my module --- unless
> it asks for and gets a python2.4-foo. So, if the script uses a non
> default version of python, or the extension module was compiled for
> a non-default version of python, I must provide pythonX.Y-fooin case
> someone somewhere has a script calling a specific version of python.
>
> There is no actual harm in always providing pythonX.Y-foo for
> all extentsion module packages (for all x.y supported and shipped
> with the package).
that's it.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgptOcFqjyec1.pgp
Description: PGP signature