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 [EMAIL PROTECTED] for more info, including pgp key ----------------------------------------------------------------------