Re: dh_python and python policy analysis
On Sat August 12 2006 09:34, Matthias Klose wrote:
First time I've seen the design goals laid out like this. Thanks, and
sorry if this is out of place.
> No, not the whole design goal. Although the document is titled
> "developer's view", the other goals should be mentioned as well.
> These are meant to work around processes in debian which are
> currently suboptimal, but unlikely to change.
>
> - The need to support more than one version of a python runtime or
> to support different implementations was seen. It takes a while
> until applications support a new version.
What is needed now is a way to prevent all but the "default" modules and
those selected by the admin from being built for all installed runtimes
so Debian can re-step forward and properly support multiple runtimes.
The new policies all-or-nothing attitude wrt modules is too much. It
effectively forces one Python only and unnecessarily discourages Python
hackers and developers because the cost of carrying all modules for all
installed versions, instead of just those modules needed for the work
being done in the different versions, can be quite high for someone
with a comprehensive installation of even one Python version.
> - The old schema of using pythonX.Y-foo packages let's land packages
> in the NEW queue, when support for another python runtime is added
> to the package. That certainly is a process, which could be
> addressed by FTP master (do not process a pythonX.Y+1-foo package
> manually, if pythonX.Y-foo is already in the archive).
If pythonX.Y+1-foo has a "-1" or "-0.x" Debian version then it is a NEW
package...
> Having pythonX.Y-foo mentioned in the control file would disallow
> binary NMU's in situations where a python runtime is dropped or
> added (the control needs to be regenerated). A solution would be
> to define an own target to regenerate the control file, which is
> not called during the normal package build. Such source package
> would not be binNMUable, but could be the target of automated
> uploads.
...as are all packages built against a new runtime (see next paragraph),
and if an X.Y runtime is dropped so are any X.Y-foo packages. So, what
is the objective of this design goal? Pushing untested packages into
the archive appears to be the result.
Python routinely spits out warnings about code breaking changes
happenning at the minor version level, surely that requires better
handling than blindly binNMUing packages (what else can mass binNMU's
be?)... the package's metainfo looks good, but nobody familiar with the
code has actually tried the combination (build, intalled, and at least
some testing) to see how it works, with any arch? That is
un-Debian-like, even for unstable, and as a 10+ year Debian user I
think I am within my rights to make such a judgement.
> - Putting extension modules for more than one python version into
> a package eases transition of these packages to the testing
> distribution, provided that the package supports to default python
> version in testing and the default python version in unstable.
> The schema used before with python-foo depending on
> python<default ver>-foo required an extra upload of every package
> containing an extension, adding new dependencies on new shared
> libraries in unstable, but not yet in testing. All packages having
> a python (<< X.Y) dependency had to be moved to testing at once.
This needed to be fixed, but more time should have been taken in the
planning because the entirety of the solution is even more suboptimal
than the previous (incomplete) policy, imo.
The thing that seems really telling in all this is that team maintenance
promises to increase the quality of packages, yet Debian's Python team
is explicitly using it to potentially decrease quality with mass
binNMUs to speed up transitions to new runtime environments.
I really hope someone shows how I've just made a fool of myself but I
don't have a lot of confidence that will happen because speed and
quality are usually a trade-off.
- Bruce
Reply to: