Daniel,
I am quite willing to convert my packages like
sparky-py, pymol-py and relax-py over to use update-alternatives
to create the required non-variant symlinks. However I still think
not conflicting the different python variants for python based
applications is of extremely dubious utility.
On Wed, Aug 13, 2008 at 12:07:55AM -0400, Jack Howarth wrote:
>Here are my two cents on this issue. In the past for the
> python variant packages I maintain, I have added conflicts
> with the view that it is undesirable to allow users to
> install multiple python variants of executable packages
Here are my two cents on this issue. In the past for the
python variant packages I maintain, I have added conflicts
with the view that it is undesirable to allow users to
install multiple python variants of executable packages.
The user should have the option to build the package against
the pyt
Pepe Barbe wrote:
> On Aug 12, 2008, at 12:25 PM, Alexander Hansen wrote:
>
>
>> What if a package has python-versioned dependencies, but does not
>> itself build public python modules (e.g. a user-executable
>> application)? Should we just pick a single python flavor in such
>> cases? T
On Aug 12, 2008, at 12:25 PM, Alexander Hansen wrote:
> What if a package has python-versioned dependencies, but does not
> itself build public python modules (e.g. a user-executable
> application)? Should we just pick a single python flavor in such
> cases? This comes up occasionally wit
