On Fri, Apr 27, 2007 at 03:12:57PM +1000, Damien Miller wrote: > On Fri, 27 Apr 2007, Mathieu Sauve-Frankel wrote: > > > > Most Python modules install under /usr/local/lib/python${MODPY_VERSION} > > > anyway, so they are fully capable of existing in parallel. > > > > But this won't be true of anything that installs anything outside > > of /usr/local/lib/python${MODPY_VERSION}. If the python stuff is > > anything like the perl stuff then there are probably quite a few py-* > > packages that do this. I believe this is what the concern is about. > > Sure, and there are a couple of simple solutions: > > 1) Don't include MODPY_VERSION in the PKGNAME of these packages > > 2) Include MODPY_VERSION but let conflicting files conflict > > 3) Include MODPY_VERSION and suffix conflicting files with MODPY_VERSION > too (e.g. /usr/local/bin/foobinator-2.4) like we do with python itself > right now > > Personally, I'd lean to #3. > > There isn't that much stuff that conflicts like this: > > cat /usr/ports/*/py-*/pkg/P[LF]* | grep -v '' | grep -v '^share/doc/py-' | > grep -v '^share/examples/py-' | grep -v '[EMAIL PROTECTED]' > > will give you an idea of how many files conflict. > > -d I think I'd like to see it as an option, e.g., MODPY_AUTOVERSIONING=Yes or some such, so that you can turn it on explicitly and check for breakage. As you said, there are bugs. So I expect this makes little sense for some modules...
There's the fact that it's going to `change' all python modules names, which plays hell with updates. So, I think the `default' python version should have no version markers, and only non default python versions should have markers. That way, people who don't play with python versions won't see a thing, and when we change the `default', pkg_add -u will do the right thing, e.g., bump packages to the new version.