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 7AEC7139694 for ; Sun, 9 Apr 2017 16:16:17 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D2DF221C012; Sun, 9 Apr 2017 16:16:08 +0000 (UTC) Received: from mail1.obsidian-studios.com (mail.obsidian-studios.com [173.230.135.215]) (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 827C9E0BE7 for ; Sun, 9 Apr 2017 16:16:08 +0000 (UTC) Received: (qmail 21517 invoked from network); 9 Apr 2017 16:16:07 -0000 Received: from unknown (HELO assp1.obsidian-studios.com) (wlt-ml@::ffff:127.0.0.1) by ::ffff:127.0.0.1 with ESMTPA; 9 Apr 2017 16:16:07 -0000 X-Assp-Version: 2.5.5(16366) on assp1.obsidian-studios.com X-Assp-ID: assp1.obsidian-studios.com m1-54566-19996 X-Assp-Session: 32A1415E890 (mail 1) X-Assp-Envelope-From: wlt-ml@o-sinc.com X-Assp-Intended-For: gentoo-dev@lists.gentoo.org X-Assp-Server-TLS: yes Received: from unknown ([fdbe:bad:a55:0:1::211] helo=localhost) by assp1.obsidian-studios.com with SMTPSA(TLSv1_2 ECDHE-RSA-AES128-GCM-SHA256) (2.5.5); 9 Apr 2017 12:16:06 -0400 Date: Sun, 9 Apr 2017 12:15:56 -0400 From: "William L. Thomson Jr." To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Reverse use of Python/Ruby versions Message-ID: Organization: Obsidian-Studios, Inc. X-Mailer: Claws Mail 3.15.0-dirty (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-sha1; boundary="Sig_/nNQVFc.H84xQfTo9K/=1eix"; protocol="application/pgp-signature" X-Archives-Salt: e8d299fb-09bf-4c25-87f1-754b6e59aa7b X-Archives-Hash: cef1ccd9d64cff2cb67370a5926723f9 --Sig_/nNQVFc.H84xQfTo9K/=1eix Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Not sure if this is practical, it may be less work if the use of Python and Ruby versions ( maybe others ) is reversed. Rather than adding all the versions that the ebuild supports. What if it only included versions it did not support? Rational When new versions are added. Ebuilds must be updated to support the new version. This can require editing a decent amount of ebuilds. Many may work fine with the new version. Making this extra needless work. From a user point of view, You cannot move to the newer version without keeping older around till all are updated to the newer version. Now one could say its the same work to mark versions not supported. But I think there is less of that. Also if something supports and older version and not newer, it may stand out more failing. Requiring someone to reduce to the older version, and maybe filing bugs to get it updated to the newer version. Python 2.7 stuff aside. I am not sure how many Python and Ruby packages break with a newer release. In pythons case I think once they support Python 3.x, there is little chance if it breaking with further 3.x releases. Not sure about Ruby. I could be very wrong and the present way of doing things being the only way. However if this is feasible it may lead to less work. It would allow all packages to move to a newer version. Also allowing punting of older sooner. This leaves the versions solely up to the eclasses. Then ebuilds simply mark the unsupported versions. Just like we do now with adding versions it does support. Which if something was say only Python 2.7. It would have a >=3D to excluded any newer version of Python. That said, we could do the same with the current way. Saying this supports Python/Ruby >=3DSLOT. Either way I do not think the current way is the best way. You have to add every version/slot to ebuilds that work fine with any version. When new ones are added, the ebuild has to be touched again. When it may work fine with a new version without requiring the ebuild to be modified. This came up with some stuff requiring ruby23 as I moved to 24. Looking around some stuff has Python 3.5 some 3.6, but all 3.4. So I will stick to 3.4 till everything is at 3.6. Otherwise no point and still have other versions. The approach mentioned above, if the packages do not have issue. I could go ahead and switch to ruby24 and pyton 3.6 across the board. Which I cannot do now till a bunch of ebulids have their targets increased. --=20 William L. Thomson Jr. --Sig_/nNQVFc.H84xQfTo9K/=1eix Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTEeldqZjmVut8bVHJNcbKkg6ozUAUCWOpePQAKCRBNcbKkg6oz UPhqAKCzrKfsaxDWdvENALDlkbwSJW0WnwCeIpKavRInKSdGi5JdZR26VO/igvw= =VV9s -----END PGP SIGNATURE----- --Sig_/nNQVFc.H84xQfTo9K/=1eix--