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.
