Re: python packaging infrastructure
Josselin Mouette writes:
> 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.
sorry, what is complicated about the solution?
please read again, these benefits aren't just aesthetic:
- working on metadata without having all packages available (which
ones?) is not just aesthetic.
- beeing able to support more python versions in a separate archive
is not just aesthetic (although not needed in the distribution,
but often requested on python-dvel).
- Identifying packages for binary NMU's to support a new python
version is not just aesthetic.
> 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?
they certainly could handled that way. If you want to change that,
please move the discussion to a more appropriate mailing list.
> 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.
It strikes me that you prefer an "easy-to-implement" over an
"easy-to-use" solution. Do you give the same commitment to support the
python-support package?
> 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.
no, it's not urgent, it has to be done for the release. I don't see
anything helpful in uploading an incomplete solution without a
discussion.
> I have not even commented on some propositions, like python-all,
python-all is orthognal, it doesn't touch the central/support scripts.
> 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.
again, I disagree on this procedure. Surely the 2.4 transition should
happen soon, but I disagree on your "urgent" argument. I don't know
how to work the best way with you on this topic, your only argument
beeing "too complicated to be implemented within two days".
you make it "urgent" by uploading something to unstable, then
observing that it may block transitions to testing. Again, Joe and me
did point out that temporarily reverting the change to dh_python does
have the same effect.
> 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.
as simple as "remove any software which doesn't work with this one
version"? Taking up your shlibs example, why not do the same with
library packages? There is a real reason we do have developed
procedures for transitions ...
Matthias
Reply to: