From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A86AA139694 for ; Tue, 11 Apr 2017 04:49:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 66E19E0CCF; Tue, 11 Apr 2017 04:49:00 +0000 (UTC) Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 12DBDE0CC9 for ; Tue, 11 Apr 2017 04:48:59 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cxnjY-00074n-6D for gentoo-dev@lists.gentoo.org; Tue, 11 Apr 2017 06:48:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Reverse use of Python/Ruby versions Date: Tue, 11 Apr 2017 04:48:45 +0000 (UTC) Message-ID: References: <20170410203822.2cbc440b@snowblower> <5950999.Gx5BNhHzAl@note> <1491857471.1661.16.camel@gentoo.org> <1491859986.1661.19.camel@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@blaine.gmane.org User-Agent: Pan/0.142 (He slipped to Sam a double gin; 505bd7027) X-Archives-Salt: 369b0f88-bdf5-4a9e-a1de-ab2b415452ce X-Archives-Hash: 4487237dbf1634160dde79e5091fc8cc 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