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

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



Le mardi 08 décembre 2009 à 21:24 +0100, Loïc Minier a écrit : 
> The goal of this set of patches is only to reflect what's de facto
>  being done in the archive, and update various bit-rotted sections of
>  the Python Policy.  It's only a first step, but also a prerequisite for
>  other changes.

Indeed it starts looking like the current packaging practices in Python
packages.

As I already told you in private, I’d like to take this opportunity to
make a much necessary change to the policy: stop advising to use
Provides: ${python:Provides}.

Rationale: let’s consider a package foo that uses python2.4 directly
(with a python2.4 shebang), and depends on python2.4-foo, provided by
python-foo, which in turn depends on python-bar. If python-bar is
rebuilt with XS-P-V: >= 2.5, it will stop providing python2.4-bar, but
python-foo will not change, and will still provide python2.4-foo. Then
foo will simply stop working.

This is why the usage of pythonX.Y-foo dependencies should not be
recommended. Packages providing public modules should all be in one of
these cases: 
      * No Provides: ${python:Provides} at all. 
      * The package has no dependency on other Python modules. 
      * The package depends on all pythonX.Y-bar, for X.Y in
        ${python:Versions} and bar in all dependencies in other modules.

Since the last solution is very suboptimal (it requires simultaneous
uploads and testing migration for all entangled packages), it should be
avoided – and anyway we should discourage use of a specific pythonX.Y
version.


Another related issue is that of packages linking to libpython to embed
an interpreter. Most of them link to the library corresponding to the
default python version of the moment. Therefore all their dependencies
should be pythonX.Y-foo and not python-foo like what is (incorrectly)
done currently. 

Maybe we should find a way to make python-support add the correct
pythonX.Y-foo dependencies instead. Of course, this makes those packages
jump right into the issue I explained before. Another possibility is to
generate python (>= X.Y), python (<< X.Y+1) in this case, but it is
precisely the kind of ideas that make transitions a nightmare.


Cheers, 
-- 
 .''`.      Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `-     future understand things”  -- Jörg Schilling

Attachment: signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=


Reply to: