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 0E569139694 for ; Mon, 10 Apr 2017 21:33:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 31C3121C1B9; Mon, 10 Apr 2017 21:31:32 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 D194D21C09E for ; Mon, 10 Apr 2017 21:31:26 +0000 (UTC) Received: from katipo2.lan (unknown [203.86.205.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: kentnl) by smtp.gentoo.org (Postfix) with ESMTPSA id 43CB933FE7D for ; Mon, 10 Apr 2017 21:31:25 +0000 (UTC) Date: Tue, 11 Apr 2017 09:30:58 +1200 From: Kent Fredric To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Reverse use of Python/Ruby versions Message-ID: <20170411093058.41553e61@katipo2.lan> In-Reply-To: References: <20170410133858.4842bbb5@katipo2.lan> <20170410163548.7d0e5348@katipo2.lan> Organization: Gentoo X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) 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: multipart/signed; micalg=pgp-sha256; boundary="Sig_/bLd10IftGSs4e97+zN0kFOe"; protocol="application/pgp-signature" X-Archives-Salt: 284cc885-0f18-4eda-bcf7-840f289d2e32 X-Archives-Hash: ad8d68437a8c51cd7a843a0bd996c2ce --Sig_/bLd10IftGSs4e97+zN0kFOe Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 10 Apr 2017 11:52:02 -0400 "William L. Thomson Jr." wrote: > > > > Meanwhile, you cannot build two parts of a given python dependency > > chain with different pythons, nor different perls. =20 >=20 > True but this is not changing how things work, just reversing. You mean going back to the old days where you'd upgrade Perl, and your syst= em would simply be broken, and you'd need to run some 3rd party tool outside o= f portage to fix it, otherwise all your compiles would randomly break because portage= had no way of knowing that everything Perl based was now broken? Or where we had python-updater for the same reasons? TARGETS is a *solution* to these kinds of problems. Don't dismiss the solut= ion simply because you don't understand the problem in the first place. Its not *ideal*, but its far better than things were. We actually *do* have many users now having effortless upgrades as a result of both targets and subslot usage, which you'd have us repeal. 1. Install new perl, subslots change, portage reinstalls everything ( portage currently does a shit job though of getting this right in all c= ases,=20 but enough users have it JustWork and perl-cleaner is only necessary be= cause they had ages of old stuff that wasn't installed with subslot binding ) 2. Globally change PYTHON_TARGETS, all things needed to be rebuilt with pyt= hon get rebuilt. "Lets not rebuild" is _not an option_. Not rebuilding is simply opting to have a broken system. You need to present a strategy for causing the rebuild, and presenting a rebuild that doesn't result in end users having a fractal of brokenness. And a "Supports everything by default, but then we mask things off as broke= n" creates a "broken by default" system. >=20 > > Right, but this is impossible with Ruby, Python, and Perl. =20 >=20 > It is done right now. The problem your describing exist now and is > addressed. This would address it the same way but reversed. Its *not* addressed now. For instance, if you recompile Perl with USE=3Dthr= eads or USE=3Ddebug, you have to recompile literally every package you have inst= alled. We have no solution for this in place, and we have tempted the idea of a TA= RGETS analogue for a few years now. The only reason it *kinda* works now is because Perl's upstream takes massi= ve efforts to ensure that when they break things, the people whos shit got broken is f= ore-warned of the impending doom, with aggressive smoke testing on the pre-releases. Subsequently, the fact we don't already have Perl with TARGETS is simply be= cause the breakage is typically fixed upstream *before* it hits us. If shit is broken sufficient that it won't work on a newer Perl, that's a t= ree breakge for us. And its soley by the grace of God that such a thing has not been significan= t enough to cause a blocker yet. Python and Ruby don't have any sort of culture to make this possible.=20 > > Perl *could* have targets, and some people think could do with it, > > but it and java are very much in different boats. =20 >=20 > Easier to deal with as a user. Less work as a developer. Which kind of user? The user who lives on the bleeding edge and doesn't min= d randomly having emerge break? What about the audience of users who bitch every time we stabilize a new ve= rsion of Perl, because they're not ready for the changes? Its a good thing nobody users Gentoo in production, because we move far too= fast for anyone to rely on our operating system for anything serious. There's plenty of codebases out there that still require older versions of = Perl, and if the *massive* catastrophe of 5.26 doesn't abate, no doubt we'll need a w= ay to concurrently install multiple Perl versions to support a legacy audience. And as soon as we have concurrent Perl versions available, a TARGETS analog= ue becomes a *necessity*, portage has no alternative. How else does portage understand the following facts: X package exists X package has 3 dependencies X package needs Perl 5.26 X therefor needs all 3 dependencies to be installed on Perl 5.26 That is, you can either slot *every* package in tree for *every* perl there= is and create a *massive* maintainer burden ( read that as: I quit ), or you introduce ta= rgets, so that portage can track the interconnectedness of packages and what they're insta= lled on. There's literally no other mechanism to do this at present. Python used to have an ENV hack that was *like* targets, except portage cou= ldn't see it, and was basically just broken by design. Thus, going back to the old way is "still have targets, just you're fucked = if you expect portage to help you with them and you'll need 3rd party tools and a daily battle with portage not un= derstanding why its dependencies are broken" =20 > Problem is simple, Targets are a PITA to deal with, ever changing. They > lead to issues when you select incompatible ones or options. Best case > wild card and let all install. But otherwise its a chore to deal with. > =20 > > We only have 2 types of option at present from the users perspective, > > "on" options, and "off" options. =20 >=20 > That sounds terrible. Lots of distros with things already turned > on/off. Gentoo should never be one. USE flags can be a PITA, but they > are a necessary evil. Its the ever changing TARGETS that are annoying, > and cumbersome to users. Read the rest of my comment. I said this is what we *currently* have. It *IS* terrible. That's why I proposed an alternative. We *currently* have a system of binary toggles, and our system basically fo= rces users to decide upon things, even if they don't care. And when packages conflict = with things that users don't care about, it forces them to care to flip the bit. ( And then = later something else forces them to unflip it, ad-infinitum ) End users don't care if mercurial needs 40 dependencies to have python 2.7 = support enabled. They just want to install mercurial and have portage do the leg work to mak= e it happen. Hence, the default should not be "Python 2.7 all the things!"... but it sho= uldn't be "fuck python2.7!" either. The default should be "Portage can turn on Python2.7 support when its deeme= d necessary due to dependency chains, but otherwise leave it off", and if users are sticklers about it, THEN they= can set a hard line of "python 2.7 all the things" or "no python2.7" We currently have the worst of both worlds. But please, actually understand the problem before attempting to tell us yo= u don't like the solutions. --Sig_/bLd10IftGSs4e97+zN0kFOe Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPZazbI/qrFT1o9rn6FQySxNmqCAFAljr+aIACgkQ6FQySxNm qCDDVA//dkT/IY8NCpPw2Wi0+MhhQ45ocsI+6FaApgknVymhvyR2zn4PgGLHlzen Mr9rPuOJ+EJRQCvrWAQnWcBmiNyecJtAKtFgdxk91OBbqxTbryCA65htrxJnCiNu kReRkAlWicD0i+cE/0wTE1Q12hrZSBUtLrxM03n6GfI7lsAquZ20Y6QiGSNefcD1 OeRyD6Hb8h6sIFNztixGIWnMRpFSY2wc/hcsvuvCTOzqsB/f2lmH6t/rzQtycyKQ mYT6qL8HPF5+SL1LOqoMRVOCQHFtYZ6YZL8vxqsTItC3KXlIkt5FrjIVdVwS6TmP tAYUxknf3G6AW5qX7LgcYZ8KlNpXxAXb5IJMusEUi4vKIRGUqJ2wowK7oeIxb3gc qci21HZy7nIMkuvZ9hJs2NXiAJCxaFHq1m3EaLeP/zUxMxsJTdjDThqe9qfTe4Be Ewui+TlvfKXGuEU3pI/GgWhNW0DiI/h6/+QlgQUxYKh9ojkjaLhih8ND5SyeEzI3 kKVtSNu8nX8FFGcFPThZKJqWrp5zCsepv6jBJOLnNPKF7lb4swt7gihHKmRP4a1n rkP+CwcDxKBBFK5qOWR/7s2wp8VMJRye4/zj0dSKqYTFlm6F8XlgV2/DsDIbjLjL ymNl28uFRgU9UsjGiqgP3+s5CKxxzQI1/7VuY2w4vW1DWFZqcko= =VdFV -----END PGP SIGNATURE----- --Sig_/bLd10IftGSs4e97+zN0kFOe--