On Sun, 31 Jan 2010 19:48:19 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <mar...@v.loewis.de> wrote: > > By the way, the part that caused me the most confusion in the language > > in the PEP was the emphasized *and their dependencies*, as if a package > > having dependencies somehow turned the problem into a factorial explosion. > > But there seems to be nothing special, according to your explanation, > > about dependencies in this scheme. > > For regular (forward) dependencies, there is indeed nothing special to > consider - they would have to exist in all versions. In practice, this > can (and was) problematic: python-zope.sendmail depends on > python-pkg-resources, python-transaction, python-zope, and 10 other > things. Before you could starting to provide python27-zope.sendmail, > all of these dependencies would have to become available in a 2.7 > version first, meaning that ten other Debian developers need to act > before you can. With the failure rate of Debian developers (who go > as often on holidays as any other volunteer), upgrading to a new Python > release could often take many months.
OK, that makes it clearer. It's an internal (and probably unavoidable) Debian social problem, not a technical one, and I see why it is an important issue. > > It seems like it would be simple enough to enhance the os packaging > > systems to allow the install path to be specified at install time, if > > that really is the only difference between the package versions. And a > > script that runs through all the installed python packages and installs > > them for a new Python version when a new version is installed should be > > as easy for other distributions as it is for Gentoo. > > However, it's also unacceptable. I can't cite the exact piece of Debian > policy, but I'm fairly sure that "build" activities are not allowed at > installation time. So actually running setup.py files is out of > question. Users who want such a thing would have to switch to Gentoo; > Debian users just want it to work :-) I'm less sympathetic to problems created by rigid policies, but that doesn't mean I'm not sympathetic :) But I don't understand how this answers the question. If the python26-zope.sendmail package doesn't run setup.py, then a python-zope.sendmail package where you specify at install time which directory to install the files to isn't going to run setup.py, either. If the only difference between a packaged python27-zope.sendmail and a packaged python26-zope.sendmail is the directory to which the files get written, why can't that be controlled at install time? Writing files to a directory must be an install activity, not a build activity. If the issue is that *deciding* what directory to install to is a build time activity...well, maybe I would be less sympathetic to a policy that is *that* rigid. > > (The os vendors are going to have > > to change details of their packaging systems if the PEP is accepted, > > so it's not as if the PEP saves the vendors work.) > > Again, I'm a little bit unclear on the motivation, also. I think it > mostly is "after years of experimentation, we have run out of ideas > how to solve all related problems simultaneously without changing > Python, so let's look for options that do involve changing Python". > > If you *really* want a list of all the simultaneous problems that > need to be solved, and an explanation of why each individual solution > has flaws, prepare for this conversation to take a few more weeks. Well, I certainly don't want the conversation to take a few more months. I'm not against the PEP, I'm making my comments and asking my questions in the spirit of making it a high quality PEP. If the motivation is "the Debian devs have concluded, after years of experimentation...", then I suppose that's what should go in the motivation section. -- R. David Murray www.bitdance.com Business Process Automation - Network/Server Management - Routers/Firewalls _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
