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
