Re: python packaging infrastructure
Le vendredi 13 janvier 2006 à 15:31 +0100, Matthias Klose a écrit :
> 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.
What exactly do you want to do with such metadata?
> - 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).
More python versions? You mean, a separate archive with a different
python version as the default?
> > 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?
First, this isn't a question of ease-of-use, but of added functionality.
Both solutions are equally easy to use, it's just one being more
complicated for more functionality. Besides that, I prefer an
easy-to-implement solution for anything that touches dh_python. This
script is written in perl, a language that few people on this list seem
to use, and it is already way too complicated for a helper script. If
you want the metadata to be handled by dpkg, the functionality should be
added to dpkg itself.
Of course this doesn't apply to python-support itself, which was written
from scratch in python.
> 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.
Looking at the mailing list archives, some people have tried to initiate
discussions about making python in Debian evolve in the recent months,
but it doesn't look like there has been much interest.
> 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 can read this as "show me the code".
About the "urgent" argument, looking at the bunch of transitions that
have happened and still have to happen in testing, we should avoid to
make the python 2.4 transition look like the previous ones, having to
migrate all python packages to testing at the same time. The number of
python packages has been increasing too much for making this possible in
a reasonable amount of time.
> > 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 ...
There are not many libraries that are present in Debian with several
versions at the same time, and I don't think they are good examples of
sane practise we should follow.
Regards,
--
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
Reply to: