[gentoo-dev] Re: Reverse use of Python/Ruby versions

[Duncan]

William L. Thomson Jr. posted on Mon, 10 Apr 2017 17:58:57 -0400 as
excerpted:

> When did changing targets to only have 1 version of Ruby, or 2 pythons
> becoming hacking. I do like how it was phrased. It shows right there the
> issue. If ANYONE has to hack around it, it sucks....
>
>> Well, you've already dismissed the users for which it works out of the
>> box... obviously they're not a proper Gentoo users if they don't break
>> their system and then complain that Gentoo is doing everything wrong
>> because they can break their systems.
>
> Only users who it works for, is those who are not wanting specific
> versions and not others. As in those who do not set the targets and let
> them be wide open, or wildcard. So they do not care what is installed.
>
> They are likely also not doing much with USE flags or other things. They
> obviously do not care what is on their systems.
>
> Most any system admin does care about what is on their system. Every
> other version is another potential for security issues etc. What good
> system adminstrator just installs needless stuff because they are lazy.

Not to step into the general argument here, but you're arguing in the 
name of gentoo users, of which I am one, and are misstating facts 
regarding the situation for users, so I thought I'd step in and correct 
that.

FWIW:

$$ equery l python
 * Searching for python ...
[IP-] [  ] dev-lang/python-2.7.13:2.7
[IP-] [  ] dev-lang/python-3.4.6:3.4/3.4m

$$ grep -r PYTHON_TARGETS /etc/portage
/etc/portage/make/useexpand:PYTHON_TARGETS="python3_4 python2_7"


Every once in awhile I decide to check to see if I can make that python3_5 
yet, with something like this (lines added between packages for clarity 
due to wrapping):

$$ emerge -vp --emptytree @world | grep python3_4 | grep -v python3_5

[ebuild   R    ] net-dns/bind-9.11.0_p3::gentoo  USE="caps filter-aaaa 
idn ssl threads xml zlib -berkdb -dlz -dnstap -doc -fixed-rrset -geoip -
gost -gssapi -ipv6 -json -ldap -libressl -lmdb -mysql -nslint -odbc -
postgres -python -rpz (-seccomp) (-selinux) -static-libs -urandom" 
PYTHON_TARGETS="python2_7 python3_4" 0 KiB

[ebuild   R    ] app-portage/mirrorselect-2.2.2-r2::gentoo  
PYTHON_TARGETS="python2_7 python3_4" 0 KiB

[ebuild   R    ] app-portage/esearch-1.3-r1::gentoo  LINGUAS="-fr -it" 
PYTHON_TARGETS="python2_7 python3_4" 0 KiB


OK, so I've not synced and updated since the end of March (30th) so that 
might be slightly dated, but as of that sync, there's still three 
packages I have installed that haven't yet been certified as having 
python3_5 support yet.

So I continue to wait before trying the python:3.5 update.  In the mean 
time, it's locally masked so as to prevent randomly pulling it in, and 
packages continue to "just work" with 2.7/3.4.

No real hassle or hacks.  No specific per-package PYTHON_TARGET settings 
for some other :3.x, but I've set the global PYTHON_TARGETS to get just 
the two versions, one 3.x and one 2.x.  There is as I said a simple 
package mask to prevent pulling in :3.5 prematurely, but that's not a 
hack, nor is it complex, it's a quite reasonable straight-forward package-
mask of a newer version because not everything's ready to handle it yet 
and I don't want to pull in a third version unless I really have to.

Yet I'm anything /but/ the claimed:

> They are likely also not doing much with USE flags or other things.
> They obviously do not care what is on their systems.

Not only do I set USE="-* ..." to prevent devs randomly screwing up my 
painstakingly set USE flags, but I also set -* in 
/etc/portage/profile/packages (a newly possible negated wildcard, FWIW) 
to negate the full cascaded @system set.

Further more, I am known to make the argument that anyone with the 
responsibility of managing what's installed on their own systems is a de-
facto sysadmin, and should be taking that responsibility very seriously, 
including the security implications of excess packages, etc, as I most 
certainly do myself.

That's also why I run the gentoo git repo and check selected commit 
messages based on what portage wants to update, including many of the -r 
updates (upstream didn't update, what's important enough for a gentoo -r 
bump and is it something I need to worry about other implications of for 
my system?), and checking out every one of the bugs listed in the portage 
update commit messages.  Of course I check upstream changelogs as well 
for selected important packages, and run live-git-9999 versions of some 
of them, checking upstream git logs as well.  (Not that I'd argue that 
/every/ responsible admin must do that, but it can certainly help in 
figuring out what went wrong with the update, sometimes, which at times 
makes my job as an admin easier. =:^)

Taking that admin responsibility seriously is also, BTW, the big reason 
I'm subscribed here, to get a heads-up on many of the major system 
changes that are likely to affect me before I'm trying to figure them out 
from emerge -vp errors.  Of course it's also because I actively chose 
gentoo as my distro and what happens in the gentoo community is something 
I care about, not just because it affects my system, but because I'm a 
part of that community and care what happens in it.

So I'm about the /last/ user to accuse of "not caring" about what's on my 
system, yet apparently because I don't have PYTHON_TARGETS wildcarded and 
didn't have to hack it to only have the two versions on the system, 
you're claiming I /don't/ care.

Of course if I wanted the 3.x version to be 3.5, I'd have a bit more 
hacking to do, but that just comes with the territory -- it's the same 
sort of grabbing patches from bugzie, etc, that I had to do when I wanted 
to run the still masked because not all packages had integrated the 
required patches yet gcc.  In fact, that's effectively what python:3.5 
*is* on my system, via package.mask, for much the same reason, not all 
packages I have merged have tested support for it yet.


Meanwhile, what you're proposing would turn that upside down.  I *would* 
have to hack things to get and keep them working then, package-masking 
the new python for versions that didn't work with it yet that hadn't been 
masked in the upstream gentoo and overlay repos, and/or googling gentoo 
bugzie and the net for patches so they would work, etc, much as I had to 
do with new gccs to get them to work, because you will have broken the 
previously working PYTHON_TARGETS system that was keeping things sane by 
only updating a package's PYTHON_TARGETS for a new python once it had 
actually been tested to work with it.

-- 
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