Re: python packaging infrastructure
Le vendredi 13 janvier 2006 à 12:28 +0100, Matthias Klose a écrit :
> > I don't understand the *need* for a specific control field. I just see
> > it as another way to implement dh_python. My opinion is that
> > "dh_python -m 2.2" is easier to implement and looks more like other dh_*
> > commands than "Python-Version: >= 2.2".
>
> As Joe did say in his reply, you have to keep this information
> somewhere, when not using dh_python.
>
> For the current Zope packaging policy, there exists such a .dzproduct
> file which holds meta information about the product (including product
> dependencies). That was added fearing a pollution of the big metadata
> file. To extract this information you have to extract the .deb and
> use your own set of tools. Exposing the metadata (one attribute) to
> the place where it belongs lets you do the query work using just the
> available tools.
>
> And maybe it's worth to add this attribute to the source package as
> well to say something about for which versions this package can be
> built.
That makes sense, but it looks like a complicated solution with only
aesthetic benefits. The Zope solution looks fine, and it's not the only
case of metadata put in the package itself. Are you also going to
propose making the shlibs information available directly in the control
file?
Furthermore, if you want to see this implemented, you'll have to find
someone else to write the necessary changes to dh_python. I will not
write nor maintain any code that parses the control file in dh_python.
This script is already one of the most complex ones in debhelper, and
everything you have proposed so far is going to make it look like hell.
Currently, dh_python meets the urgent requirement: allowing the python
version to change without having to rebuild all python-only packages. I
have proposed to upload very soon the necessary changes to handle a
limited set of python versions. Packages can start to migrate smoothly
without breaking anything. But if at the same time you're filing RC bugs
on debhelper, we're not going anywhere.
I have not even commented on some propositions, like python-all, the new
control file field, or shipping several binary modules in a single
package, because I believe they are so complicated it will take way too
much time to implement them, and still, maintainers will be reluctant to
use them. Furthermore, it is my opinion we are already too late in the
release process to introduce such radical changes for etch. If we want
the python2.4 transition to happen soon - and it's beginning to be an
urgent matter - we'd better make it with something that looks reasonable
to implement in a few days, not in two months.
And while I'm digressing, changing the python policy so that only one
python version at a time is supported would be much simpler. Simpler for
you as python maintainer, simpler for people like me developing
intermediate layers, and simpler for package maintainers. I happen to
like simple things.
Regards,
--
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
Reply to: