> 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. Now they have that new grand scheme involving tons of symbolic links; actually, they have two of them (python-central and python-support). While this is perfect in theory, it's not very robust (Barry can probably better report all the failure modes). I guess (without knowing) that this is really what triggered the PEP. > 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 :-) > (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. Regards, Martin _______________________________________________ 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
