On Mon, Sep 21, 2009 at 12:35:19AM +0200, Wolodja Wentland wrote: > On Sun, Sep 20, 2009 at 22:18 +0200, Bernd Zeimetz wrote: > > Wolodja Wentland wrote: > > [ placed on top because this is the main point ] > > > > If however the *env python scheme is enforced in the policy the problems > > > I outlined in my original post are solved without additional problems > > > (?). If there are any i would like to know about them! > > > > There are probably not more problems than the few which were mentioned > > already, > > but they are such large issues that thinking about enforcing the use ov env > > is > > absolutely insane. > > I really don't get it. How could it possibly be better to have a wild > mix of programs that use '/usr/bin/python' and those using '/usr/bin/env > python' than having *one* predictable, consistent standard enforced in > the policy with *very* few exceptions. A situation in which packages not > using the enforced scheme are considered buggy and in violation of > policy and only *very* few packages are granted the right to use the > alternative scheme?
This is indeed desired and the policy says to use /usr/bin/python, for reasons explained in this thread already. Maybe the applications using /usr/bin/env should get a bug filled, I agree with that. And I would even argue that /usr/bin/env is not allowed as an exception, the tools needing this could provide several versions of their app for each suppored python version, e.g. py.test, py.test2.4, py.test2.5. And if you want to use it with a non-debian environment you can either install the tool in that environment or set the environment up so you can do "/usr/local/bin/python2.6 /usr/bin/py.test", which is no different from now. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
