On Fri, 2010-01-15 at 16:53 -0500, Toshio Kuratomi wrote:
> On Fri, Jan 15, 2010 at 11:45:05AM -0500, David Malcolm wrote:
> > On Fri, 2010-01-15 at 10:55 -0500, Toshio Kuratomi wrote:
> > > This reasoning (needed for testing) doesn't appeal to me at all. The
> > > general case should be that we s
On Sat, 2010-01-16 at 13:09 -0500, Toshio Kuratomi wrote:
> On Sat, Jan 16, 2010 at 12:45:24PM +0200, Ville Skyttä wrote:
> >
> > But what's the benefit of alternatives for this? Is the intent to provide
> > sysadmins a way to change which python version of an app would be the
> > system
> > d
On Sat, Jan 16, 2010 at 12:45:24PM +0200, Ville Skyttä wrote:
>
> But what's the benefit of alternatives for this? Is the intent to provide
> sysadmins a way to change which python version of an app would be the system
> default?
>
> If not, why not just pick what we want to be the default for
On Saturday 16 January 2010, Till Maas wrote:
> On Sat, Jan 16, 2010 at 11:14:53AM +0200, Ville Skyttä wrote:
> > On Friday 15 January 2010, Jesse Keating wrote:
> > > Alternatives is system wide, but it can be per application.
> >
> > Per application alternatives, as in alternatives(8)? How?
>
>
On Sat, Jan 16, 2010 at 11:14:53AM +0200, Ville Skyttä wrote:
> On Friday 15 January 2010, Jesse Keating wrote:
>
> > Alternatives is system wide, but it can be per application.
>
> Per application alternatives, as in alternatives(8)? How?
If two versions of each application with different sheb
On Friday 15 January 2010, Jesse Keating wrote:
> Alternatives is system wide, but it can be per application.
Per application alternatives, as in alternatives(8)? How?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, Jan 15, 2010 at 4:45 PM, David Malcolm wrote:
>
> = Support files for the Python language =
> /usr/bin/g-ir-scanner
I don't see any intrinsic value in having both versions of
g-ir-scanner available; this one should be in the other category, it's
just a program which happens to be impleme
On Fri, Jan 15, 2010 at 11:45:05AM -0500, David Malcolm wrote:
> On Fri, 2010-01-15 at 10:55 -0500, Toshio Kuratomi wrote:
> > This reasoning (needed for testing) doesn't appeal to me at all. The
> > general case should be that we switch applications in rawhide from python2
> > to python3. Test t
On Fri, 2010-01-15 at 10:55 -0500, Toshio Kuratomi wrote:
> On Fri, Jan 15, 2010 at 12:31:41PM +0100, Thomas Spura wrote:
> > Am Donnerstag, den 14.01.2010, 22:54 -0500 schrieb Toshio Kuratomi:
> > > On Thu, Jan 14, 2010 at 04:56:23PM -0500, David Malcolm wrote:
> > > > python3 is in rawhide and I'
On Fri, Jan 15, 2010 at 12:31:41PM +0100, Thomas Spura wrote:
> Am Donnerstag, den 14.01.2010, 22:54 -0500 schrieb Toshio Kuratomi:
> > On Thu, Jan 14, 2010 at 04:56:23PM -0500, David Malcolm wrote:
> > > python3 is in rawhide and I'm hoping to build out the Python 3 stack
> > > (help would be most
Am Donnerstag, den 14.01.2010, 22:54 -0500 schrieb Toshio Kuratomi:
> On Thu, Jan 14, 2010 at 04:56:23PM -0500, David Malcolm wrote:
> > python3 is in rawhide and I'm hoping to build out the Python 3 stack
> > (help would be most welcome!)
> >
> > I've run into a snag with the plan of building out
On Thu, Jan 14, 2010 at 04:56:23PM -0500, David Malcolm wrote:
> python3 is in rawhide and I'm hoping to build out the Python 3 stack
> (help would be most welcome!)
>
> I've run into a snag with the plan of building out parallel python 2 and
> python 3 stacks [1]: What do we do about executables
On Thu, 2010-01-14 at 18:49 -0500, David Malcolm wrote:
>
> Thanks. As I understand it, the alternatives system is a host-wide
> configuration setting: only one set of things can be at use at a time on
> a host; that seems too blunt for this, alas - I think people should be
> able to use a mixtur
On Thu, 2010-01-14 at 22:29 +, Jonathan Underwood wrote:
> 2010/1/14 David Malcolm :
> > Anyone got any better ideas? Thoughts about which of the above is
> > preferrable?
>
> I am not sure it qualifies as "better" than your suggestions... but
> the problem of different executables with the s
2010/1/14 David Malcolm :
> Anyone got any better ideas? Thoughts about which of the above is
> preferrable?
I am not sure it qualifies as "better" than your suggestions... but
the problem of different executables with the same name providing
equivalent functionality via a different implementatio
python3 is in rawhide and I'm hoping to build out the Python 3 stack
(help would be most welcome!)
I've run into a snag with the plan of building out parallel python 2 and
python 3 stacks [1]: What do we do about executables that live
in /usr/bin ?
For example if we have a 'console_scripts' in a
16 matches
Mail list logo