[gentoo-dev] Re: proposal for consistency between {RUBY,PYTHON,PHP}_TARGETS

2012-11-26 Thread Nicolas Sebrecht
The 24/11/12, Diego Elio Pettenò wrote:

 No. Being consistently stupid is not a good reason to be consistent.

Stop being fallacious, please.

 And since as I said the RUBY_TARGETS interface is designed to be _usable
 by Ruby developers_, being consistent and breaking that, is not
 something I would care about.

The request is for Gentoo administration. So, talking about developers
of a language is not the question. 

I am a ruby developer and having ruby18 or ruby_1_8 is not much a
problem. There are a lot of package names not matching a command name
and it's not a problem either.

Talking of ruby developers when it comes to Gentoo admins is wrong.

-- 
Nicolas Sebrecht



Re: [gentoo-dev] Re: proposal for consistency between {RUBY,PYTHON,PHP}_TARGETS

2012-11-26 Thread Diego Elio Pettenò
On 26/11/2012 00:20, Nicolas Sebrecht wrote:
 The request is for Gentoo administration. So, talking about developers
 of a language is not the question. 

Gentoo administration? What on earth would that be?

 I am a ruby developer and having ruby18 or ruby_1_8 is not much a
 problem. There are a lot of package names not matching a command name
 and it's not a problem either.

It is a problem if that means having to change hundres of packages,
three eclasses, and every developer's configuration.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/



[gentoo-dev] Re: proposal for consistency between {RUBY,PYTHON,PHP}_TARGETS

2012-11-24 Thread Duncan
Peter Stuge posted on Sat, 24 Nov 2012 20:20:27 +0100 as excerpted:

 Jauhien Piatlicki wrote:
 PHP_TARGETS=5.3 5.4
 RUBY_TARGETS=1.9
 PYTHON_TARGETS=2.7
 
 But maybe it would be too problematic?
 
 What will you do with PYTHON_TARGETS=python2_7 python3_2 pypy1_9
 jython2_5 then?
 
 That's an excellent point. Thanks!
 
 Thinking out loud another round: _TARGETS is an interface by Gentoo,
 so maybe it would not be such a bad idea to use existing Gentoo
 identifiers there, ie. (a subset of?) PMS version specifications.

On the net-nntp/pan upstream (which I've been involved with for about a 
decade now), but I'm sure it's not original to pan, wishlist bugs that 
would be nice to fix someday, maybe when all the other bugs are fixed, 
or if someone profiles all the patches, does a bunch of testing, etc... 
these sorts of wishlist bugs are set to milestone target bluesky.

IMO, that's exactly what this is, a target bluesky wishlist item.  
Except here it's worse, because the change will be very end-user visible, 
requiring configuration adjustments on running/working systems, for 
little reason, and unlike someone providing patches, someone can't 
reasonably volunteer to go around and fix everyone's systems for them.

Yes, it'd be nice to have consistent *_TARGETS values.  But IMO it's a 
whole lot of potentially bug triggering work on packages that are working 
just fine as they are, for comparatively little gain.  What's worse is 
that these changes will require end-user configuration changes.  So 
people aren't impressed with the inconsistency.  They'll be far LESS 
impressed if things break due to bugs, and I know a lot of former 
gentooers who already complain about both that, and about the need for 
constant attention to config changes, reading news and the various elog 
style notifications and jumping thru the necessary hoops to keep things 
working, etc.  We don't need MORE of those hoops to jump thru, and at 
this point, I just don't see that it's worth it.  Rather, it's almost at 
the level of change for change' sake, or at least, it's sure going to 
look like that to the users having to adjust their *_TARGETS vars.  
That's far less impressive than a bit of inter-package *_TARGETS 
inconsistency.

So like someone suggested in an earlier thread on simply changing some 
name or other, I take it if we're discussing this, all the REAL bugs are 
already fixed and there's nothing else more important left to do, right?  
Because that's about the point at which I think we should be focusing on 
things like this.

Just MHO, no more, no less.

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman