|
Home > Archive > Debian Developers > July 2006 > The new python policy and packaging
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
The new python policy and packaging
|
|
| Manoj Srivastava 2006-07-27, 1:29 pm |
| Hi,
[Please keep the CC to debian-devel, or please CC me, if yu
are replying to this on debian-python@lists.debian.org, since
I am not subscribed to that list]
I have been trying to ensure that my SELinux related packages
which have a Python component are compliant with the new Python
policy[1]. The wiki page for the policy[2] seems to be mostly a dh_python
usage manual, and defers to dh_python to set up the variable
substitutions correctly, so I have been trying to write up my own
manual based on the policy and reverse engineering dh_python.
In the course of this, there were points which I found very
confusing in the Python policy which I think need to be cleared up.
Section 2.2:
Firstly, public modules are supposed to be packaged in a
package called python-foo. What about public extensions? section 2.2
talks about naming, and also talks about supporting current python
version. The last sentence in section 2.2 says:
"This requirement also applies to extension modules; binaries
for all the supported Python versions should be included in
a single package."
It is not clear whether "This requirement" refers to the naming, or
the support.
Perhaps policy should explicitly say "Public modules _and
extensions_ should be packaged with a name of python-foo," (assuming
that I now have the correct interpretation).
(BTW, the wiki page seems to differentiate more strongly
between modules and extensions:
python extension: a .so file for use by Python applications
python module: a .py file for use by Python applications)
section 2.4:
Can anyone explain why if my Python packages depend on Python
version 2.4, and selinux.so for Python 2.4, it should depend on
python2.4 and python2.4-selinux; but when the default changes to 2,4,
my package dependencies would beed to change to Python (>= 2.4) and
pythong-selinux? (This according to section 2.4 of [1])
It is not clear why a package that depends strictly on python
2.3, which is the current default, should fall into paragraph one of
the section, and not into paragraph two.
,----[ section 2.4, paragraph 1 ]
| Packaged modules available for the default Python version (or many
| versions including the default) as described in Module Package Names,
| Section 2.2 must depend on "python (>= X.Y)". If they require other
| modules to work, they must depend on the corresponding
| python-foo. They must not depend on any pythonX.Y-foo.
`----
,----[ section 2.4, paragraph 2 ]
| Packaged modules available for one particular version of Python must
| depend on the corresponding pythonX.Y package instead. If they need
| other modules, they must depend on the corresponding pythonX.Y-foo
| packages, and must not depend on any python-foo
`----
I assumed it fell into paragraph one, since it is explicitly
stated so in policy. Logically, though, only paragraph two should
apply. In any case, this must be disambiguated.
section 2.5:
The second paragraph of section 2,5 is a duplicate of the
second paragraph of section 2,4. This seems like a cut-and-paste
error, and directives appear to be missing from section 2.5. There
should be something about providing pythonX.Y-foo if your package
provides an extension for version X.Y of python.
I'll add to this list as I get further along in my reading.
manoj
[1]http://www.debian.org/doc/packaging-manuals/python-policy/
[2]http://wiki.debian.org/DebianPython/NewPolicy
ps: I think policy should state clearly how it expects the various
fields in the control file to be initialized, rather than leaving it
mostly unstated and deferring to an external helper program, but that
is another thread
--
Without fools there would be no wisdom.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2006-07-28, 1:23 am |
| On Thu, 27 Jul 2006 14:15:47 -0500, Joe Wreschnig <piman@sacredchao.net> said:
> On Thu, 2006-07-27 at 11:56 -0500, Manoj Srivastava wrote:
[vbcol=seagreen]
> 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.
> This is made clear in the policy;
> http://www.debian.org/doc/packaging...kages.html#s2.1
Inconsistently so, as noted above.
> If the wiki uses "modules" to refer to only pure Python modules, it
> is incorrect.
Then I suggest someone who knows about Python policy please
update the Wiki page to correct it.
[vbcol=seagreen]
[vbcol=seagreen]
> 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.
> If you always need Python 2.4, even when Python 2.5 is the default,
> then the python2.4-foo deps are still appropriate.
Right. But that is an answer to a different question.
[vbcol=seagreen]
> I would not consider modules for only 2.3 to be available "for the
> default Python version", unless a simple rebuild would make them for
> only 2.4 after 2.4 becomes the default (XS-Python-Version 2.3 versus
> XS-Python-Version current). And if your module supports more than
> one version, you should be packaging it for more than one version,
> meaning it unambiguously falls under 2.4.1.
Umm. That does not follow. My package foo, say, needs the
version 2.2 or 2.3. The default is version 2.3.
"Packaged modules available for the default Python version (or
many versions including the default)..."
It does seem reasonable to me that since 2,3 is the default
python version now, and my package is available for the default
python version, it should follow the directive in para one.
The semantics of "available for the default version" seem to
be very amenable for misinterpretation, so we should clarify it.
> The language could perhaps be clearer, but you're the first person
> to have problems with it (and you figured it out as well), so I
> think it's adequate.
I did not actually figure it out, there was a discussion on
IRC, and the alternate meaning was pointed out to me, and then it
did appear to be more reasonable.
I posit the wording is not adequate as it is, and should be
targeted for clarification.
[vbcol=seagreen]
> Yes, this is a real mistake, probably my fault. The second paragraph
> can probably just be deleted.
> The Provides: has nothing to do with extensions. It's solely to do
> with whether or not version-specific modules or programs need to use
> your module. It can be appropriate for pure Python modules, or
> pointless for extensions that are not required by anything
> version-specific.
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).
[vbcol=seagreen]
> Until dh_python's behavior stops changing every other week this is
> an act of futility. I tried to emphasize this previously, but it
> seems to be a lost cause. Packaging Python programs is going to
> require debhelper or CDBS, as well as pysupport or pycentral, for
> the forseeable future. I realize this will make you very unhappy,
> but it's just something you will have to deal with for now.
Well, then, I shall just do my best to interpret how dh_python
behaves, and follow that in my packages. But reports would be
downgraded until we have a real Python policy, since punting to
dh_python is clearly unacceptable for a policy specification.
Filing bugs on my packages asking me to use helper packages
shall be closed with extreme prejudice 
manoj
--
Hoare's Law of Large Problems: Inside every large problem is a small
problem struggling to get out.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Pierre Habouzit 2006-07-28, 1:23 am |
| |
|
|
|
|