se? Is this the
approach that maintainers are taking?
If so, would it not perhaps make more sense to have python packages
detect the version of /usr/bin/python at build time, and adjust
themselves accordingly?
The only problem would be the need for a shlibdeps equivalent or
whatever
--
Pete
n sid/
or
deb http://www.wilmascope.org/debian potato/
(along with potato versions of the current omniORB packages)
There are also "WilmaScope" .debs in those repositories, but you'll need
evil non-free apt lines to get Java3D etc...
Warning: these repositories are on sourceforge, install
es from 1.5.2 -> 2.0) in Python :(
> That is also an official answer to my previous concern: Python 2.0
> and 1.6 are not GPL compatible. Hrmpf.
If the IP transfer is made, these two releases will both become
GPL-compatible.
--
Peter Eckersley http://www.cs.mu.oz.au/~
On Tue, Jan 16, 2001 at 09:56:46AM +0100, Stephane Bortzmeyer wrote:
> On Tuesday 16 January 2001, at 11 h 45, the keyboard of Peter Eckersley
> <[EMAIL PROTECTED]> wrote:
>
> > clause requiring legal disputes to be settled under the jurisdiction of the
> > State
llowing:
* The GPL is heavily affected by jurisdiciton
* The GPL may in fact need to have different flavours for different
countries, and may not work at all in some places
* This is a major problem for Free software
* It is essential to lobby IP-regressive legislatures to protect the
feasibility
ive away the absolute minimum of concessions to be compatible with
the Python 1.6+ license. Get a lawyer to look at it before you use it!
Also, if you do get advice that it is okay, post so back here, so that I can
put it in my code ;)
--
Peter Eckersley http://www.cs.
es on. To resolve the dependency problems, any python code using
/usr/bin/python-gpl-compat should depend on (initialy virtual)
python-extension-gpl-compat packages.
Of course there is still Jpython and stackless python, but if I understood it
correctly nobody was suggesting that /usr/bin/python
7 matches
Mail list logo
