Re: The Python Registrar
On Sun, Feb 24, 2002 at 05:54:24PM -0500, Jim Penny wrote:
> On Sun, Feb 24, 2002 at 10:35:47AM +1100, Donovan Baarda wrote:
> > On Sat, Feb 23, 2002 at 03:31:26PM -0500, Jim Penny wrote:
[...]
> > The packages, provided they are built right, will be pretty self
> > explanitory. Installing "python-foo" will install python-foo for the default
> > python, "python2.1-foo" will install python-foo for python2.1. You are right
> > that if "python-foo" happens to be a python-central package, it will also
> > install for any other installed and supported python versions, but I can't
> > see that this is a problem. If it is a python-central package, there will be
> > no corresponding "python2.1-foo" package.
>
> This is only NOT a problem if you
> 1) guarantee that the amount of total space of python-central
> registerable packages is negligible.
> or 1a) have a way of allowing the root users to easily override
> installation of undesired packages.
> and 2) have a way for the packager to express exactly which pythons the
> package is known to run under.
>
> Now, some of these proposals have either not expressed, or allowed to
> be open-ended 2). If you have a system that permits only a finite list
> of pythons to be expressed, I have no real objection to part 2).
The modifications I've proposed for python-central will ensure a
python-central package will indicate the supported python versions in it's
dependancies, in the form "Depends: pythonX.Y | pythonX.Y+1 | ...,
python-central".
> If you are arguing that total space is negligible on end-user machines,
> but not negligible on Debian repositories, well, this is where you begin
> to lose me. See "What Evidence", below.
I don't understand.
The size on repositories will be un-affected by a python-central solution,
except that a small "python-central" package will be added. The alternative
is to have duplicated pythonX.Y-foo packages for every supported version of
python, which would be much larger.
The size on end-user machines will be reduced by a python-central solution,
because the *.py files will be symlinked to a single source for all
installed versions of python, rather than duplicated by multiple
pythonX.Y-foo packages.
The only possible way that size on end-user machines would be increased,
would be when a system has multiple versions of python installed, with
python-foo installed and supporting them all, when the sysadmin only wanted
python-foo for one of the python versions. In this case, there would be
(working) python-foo *.pyc and *.pyo files for all installed versions of
python, when only one set was needed.
[...]
> > Of course, the current policy does not require that packagers support all
> > versions of python, so there is no garrentees that "python2.1-foo" will
> > exist, or that a python-central "python-foo" will support python2.1. A quick
> > glance at the dependancies will tell you what python-foo works for.
>
> BTW: I agree with this, and there in fact sould be no such policy. If a
> package works only under 2.2, it may be very difficult to backport to
> 2.1 or 1.5.2. I do believe, however, that policy should be amended to
> encourage packagers to support as wide a range of pythons as possible,
> and to accurately record/report for which pythons the package is
> available and has been tested.
I'm not sure about encoraging support for as wide a range of pythons as
possible. I think encoraging support for the "default" python is enough.
People can submit wish-list bugs against packages if they want support for
additional versions. However, a mechanism that makes supporting multiple
versions easier is going to help :-)
> > You don't have to re-install every time an additional python is introduced.
> > If python-central becomes accepted as part of the policy, installing a new
> > python will compile all python-central modules for the new python in the
> > pythonX.Y's postinst.
> >
>
> Either you are misreading, or you are ignoring the import of this
> argument.
>
> Suppose you are not a python specialist, but just a root administrator
> who has been asked to install an extra python on a multi-user machine.
> Which is the easier rule for you to remember and follow?
[...snipped examples...]
I don't get this. AFAIKT, the only difference between current policy and
current policy + python-central is "python-foo" _might_ support other
pythonX.Y's in addition to the default python. This can be determined by
looking at python-foo's dependancies. The only thing python-central removes
is the option of _not_ having python-foo for a compatible pythonX.Y
when it is only needed for pythonZ.W.
We already have one C-extension package that supports multiple pythonX.Y's
like this; python-pqueue. (Which I think is not a good idea BTW, multiple
pythonX.Y-pqueue's would have been better in this case).
> What kind of evidence should be considered in determining if
> python-central should be made part of policy?
>
> How many pure python modules are there? What is their total size
> in .deb form? What is their size on the client? How much do the .pyo
> and .pyc files add to this? How much would it add to the Debian
> packages file to have them packaged analogously to C-extension modules?
There are a variety of ways that pure-python packages could be packaged
similarly to C-extension modules. Some of them waste space on the archives,
some waste space on end-user machines, all of them complicate package
building compared to a "python-central" solution.
Your post suggests packaging multiple pythonX.Y-foo packages with
pre-compiled *.pyc and *.pyo files in them. IMHO, this is not a good idea,
when a single *.py can be used to generate them at installation for multiple
compatible versions of python.
> If you make the engineering argument that the amount of space saved
> on Debian mirrors is substantial, (or maybe that amount of space saved in
> the Packages file is substantial); and that the amount of space wasted
> on user machines is not substantial (or perhaps does not matter); and
> that python-central, or its cognate, saves substantial packager time;
> and that the thought process of B) above is not unduely burdensome on
> our users (or at least sysadmins); then you have a slam-dunk case.
I suspect most of the "packager time" argument has to come from packagers. I
would dare to guess that python-central will be much easier than multiple
pythonX.Y-foo packages, but that's up to them.
I don't think any pure-python multi-version alternatives can save space over
a python-central solution, either for achives, or for end-users.
> Otherwise, you are talking about engineering tradeoffs. And I have seen
> no numbers, not even back of the envelope calculations, about the impact
> of these tradeoffs. And, we clearly have wildly different intuitions on
> the impact of these decisions.
possibly because we have wildly different understandings about how the
various alternatives will work :-)
> That is, I want to know more. Nothing should be made part of policy
> because it can be done, not even because it can be easily done. There
> has to be an argument that it should be done.
True. But I don't think any effort would have been expended on this if there
wasn't a need for it.
--
----------------------------------------------------------------------
ABO: finger abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Reply to: