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

Re: RFC: Proposed updates to the Python Policy to reflect current practices



Luca Falavigna <dktrkranz@debian.org> writes:

>  ---
> |  1.2. Main packages
> |
> |    At any time, the `python' package must ensure that the binary
> |    `/usr/bin/python' is provided.
>  ---
>
> This is currently not a binary, but a relative symlink pointing
> to ./pythonX.Y (where X.Y is the current supported Python version).

It seems to be common practice to use the term “binary” for things that
often aren't binaries, but merely lead to a program being run. You're
right that it's confusing.

> Should this point be reworded to avoid confusion?

Yes, I think this would be clearer as “program”. I have no problem with
leaving it unstated that it may be a symlink to another file.

>  ---
> |  2.2. Module Package Names
> |
> |    Public modules should be packaged with a name of `python-<foo>',
> |    where <foo> is the name of the module.
>  ---
>
> Since this can lead to some misunderstandings, I'd add that this
> naming scheme applies to binary packages, things are relaxed speaking
> of source package names, where we usually conform to upstream names.

I would also prefer to avoid ambiguity with the separate Python concept
of “package”. Perhaps:

    Public Python packages or modules should be packaged with a Debian
    package name of ‘python-<foo>’, where <foo> is the name of the
    Python package or module as used in the ‘import’ statement.

>  ---
> |  3.1. Programs using the default python
> |
> |    If the program needs the python module `foo', it must depend on
> |    `python-foo'.
>  ---

s/python module/Python module or package/

> This is conflicting with 2.2: it has been told packages providing
> <foo> module *should* be named as python-<foo>, while here it has been
> told programs needing <foo> module *must* depend on python-<foo>,
> which could eventually follow another naming scheme. I think we should
> strictly enforce 2.2, or relax 3.1.

Right. This doesn't distinguish “needs a module” from “needs a public,
third-party module”, I think it should.

-- 
 \      “The most common way people give up their power is by thinking |
  `\                               they don't have any.” —Alice Walker |
_o__)                                                                  |
Ben Finney

Attachment: pgpu4pVvWsofB.pgp
Description: PGP signature


Reply to: