Piotr Oz.arowski schrieb: >> - 2.5 is superseded by 2.6; currently there doesn't seem to be >> a reason to ship 2.5 and modules for 2.5 with the next stable >> release. The upstream 2.5 maintainance branch doesn't see bug >> fixes anymore, only security releases will be made from this >> branch. > > What about a smooth upgrade path for those who use Python2.5 for their (3rd > party) applications? I think Python 2.6 should be default in Squeeze and > Python > 2.4&2.5 in supported.
always having the default version of the stable release included in the next release would mean that Debian releases keep up with Python release, or we would end up shipping more than two 2.x versions. Same if 2.7 gets released in time. >> The path /usr/lib/pythonX.Y/site-packages is not found on sys.path >> anymore. > > is "local/" missing in this path or do you want to simply rename site-packages > into dist-packages? /usr/local/lib/pythonX.Y/site-packages isn't found in sys.path as well. >> About the name: Discussed this with Barry Warsaw and Martin v. Loewis, >> and we came to the conclusion that using the same directory name for >> both locations would be the most consistent way. >> >> This change should make the request to conditionalize the inclusion of >> /usr/local/lib/pythonX.Y/site-packages into sys.path obsolete. > > if I understand this correctly, local installations (including ez_install > ones) > will use /usr/local/.../site-packages and the ones used by administrators (who > know about --install-layout=deb) /usr/local/.../dict-packages, and the > site-packages will not be in default sys.path, right? No, /usr/local/lib/pythonX.Y/site-packages will only be used if you install your own python, and use this interpreter to call setup.py install. When using the python (>= 2.6) provided by Debian without to call setup.oy install --install-layout=deb, the installation will go to /usr/local/lib/pythonX.Y/dist-packages, without --install-layout it will go to /usr/lib/pythonX.Y/dist-packages. > If yes, then although I love the idea of "solving" the `sudo easy-install > MyModule` really annoying issue (last time I raised it here[1], see also > Christoph's "Why you should not use easy_install carelessly on Debian"[2]), > what's a purpose of having local site-packages if installing there will have > no > effect. Or do you want to keep it for local *Python* interpreter > installations? It is not kept, it is the standard site-packages for "local *Python* interpreter installations". > I really like the idea of using the same location for both tools, please note > that you'll have to change pycentral to use something like /usr/lib/pyshared > (for Python extensions) where is the advantage of having a /usr/lib/pyshared? > yes, that's a problem, but I think we should do it step by step, first: > all packages should ship .py and .so files in the same directories (so that > dpkg can handle conflicts again), then we'll think about using common entry in > sys.path (and/or merging helper tools or making it possible to choose one of > them to do all the stuff) I can agree on "later", if it does mean "for squeeze". >> The disadvantage of this approach is the limitation to a specific set >> of python versions (the package will have a dependency of the form >> "python (<< X.Y)", which we already have for architecture dependent >> packages containing extensions. This would add this kind of >> dependency to all architecture independent python-* modules and then >> requires an upload of these packages for each python transition as >> well. Afaics this would not affect a transition or a set of >> transitions to testing, because no new dependencies on new versions of >> shared libraries are introduced during these uploads. This approach >> certainly has an impact on the ftp archive and its mirrors, but I >> can't say if this would be an issue or not. > > I don't like python (<< X.Y) dependencies, it's so... old-policy like. > Not a good idea, IMHO well, just "not liking" is a weak argument. >> - The removal of a python version will cause the need for massive >> rebuilds. because many python extensions currently have >> dependencies of the form pythonX.Y-foo. There is nothing what >> can be done now for the upcoming removal, but those dependencies >> should not be there by default. This is 2.4 of the python policy, >> but many packages tend to ignore that. > > python-support supports namespace packages and it does it good. I didn't want > it to be enabled by default but since Joss provided a way to disable it (see > #459468) I think it's OK. > > python-central should implement the same behaviour, IMHO As I did write above, the support for namespace packages should be implemented using diversions. It's ok to generate these by a packaging helper. > Just one more issue: what about "current" issue? Although I protested when > others wanted to remove it, now I agree it's useless. All packages that depend > on it (Python applications mostly) should use private directories and thus not > pollute the global namespace (we should add this to the Python policy, IMO) "current" is also useful to only provide a public module for just the default version. I'm unsure what you mean with when talking about the above mentioned "issue" Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
