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 2C01F139694 for ; Mon, 10 Apr 2017 06:37:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A73FF21C07B; Mon, 10 Apr 2017 06:37:41 +0000 (UTC) Received: from smtp.gentoo.org (mail.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 5318FE0D91 for ; Mon, 10 Apr 2017 06:37:41 +0000 (UTC) Received: from [10.99.45.219] (public-gprs385833.centertel.pl [37.47.138.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 6FB84340988 for ; Mon, 10 Apr 2017 06:37:39 +0000 (UTC) Date: Mon, 10 Apr 2017 08:37:34 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: 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: quoted-printable Subject: Re: [gentoo-dev] Reverse use of Python/Ruby versions To: gentoo-dev@lists.gentoo.org From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= Message-ID: <8F38F35E-A4CE-4530-880C-E409E672F253@gentoo.org> X-Archives-Salt: 28af1bad-edf6-4dce-bb95-c4a724c988d1 X-Archives-Hash: c610141ec4c59011d64ee704e64dc9e5 Dnia 9 kwietnia 2017 18:15:56 CEST, "William L=2E Thomson Jr=2E" napisa=C5=82(a): >Not sure if this is practical, it may be less work if the use of >Python and Ruby versions ( maybe others ) is reversed=2E Rather than >adding all the versions that the ebuild supports=2E What if it only >included versions it did not support? It is always nice when a person who: a=2E did not bother to do any research on the topic (such as reading previ= ous posts or even asking the relevant teams), b=2E has barely any clue (if any at all) about Python ecosystem or package= maintenance in Gentoo,=20 c=2E is either completely ignorant of how Python packages worked in the pa= st (which quite proves the points made above) or presumes that they were ch= anged for no reason by incompetent developers, decides that the workflow of Python team needs to be changed and goes to d= iscuss it on the mailing list with other people who barely do any Python wo= rk=2E > >Rational >When new versions are added=2E Ebuilds must be updated to support the new >version=2E This can require editing a decent amount of ebuilds=2E Many ma= y >work fine with the new version=2E Making this extra needless work=2E 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=2E > >Now one could say its the same work to mark versions not supported=2E But >I think there is less of that=2E Also if something supports and older >version and not newer, it may stand out more failing=2E Requiring someone >to reduce to the older version, and maybe filing bugs to get it updated >to the newer version=2E > >Python 2=2E7 stuff aside=2E I am not sure how many Python and Ruby packag= es >break with a newer release=2E In pythons case I think once they support >Python 3=2Ex, there is little chance if it breaking with further 3=2Ex >releases=2E Not sure about Ruby=2E > >I could be very wrong and the present way of doing things being the >only way=2E However if this is feasible it may lead to less work=2E It >would allow all packages to move to a newer version=2E Also allowing >punting of older sooner=2E This leaves the versions solely up to the >eclasses=2E Then ebuilds simply mark the unsupported versions=2E Just lik= e >we do now with adding versions it does support=2E > >Which if something was say only Python 2=2E7=2E It would have a >=3D to >excluded any newer version of Python=2E That said, we could do the same >with the current way=2E Saying this supports Python/Ruby >=3DSLOT=2E > >Either way I do not think the current way is the best way=2E You have to >add every version/slot to ebuilds that work fine with any version=2E When >new ones are added, the ebuild has to be touched again=2E When it may >work fine with a new version without requiring the ebuild to be >modified=2E > >This came up with some stuff requiring ruby23 as I moved to 24=2E Looking >around some stuff has Python 3=2E5 some 3=2E6, but all 3=2E4=2E So I will= stick >to 3=2E4 till everything is at 3=2E6=2E Otherwise no point and still have >other versions=2E > >The approach mentioned above, if the packages do not have issue=2E I >could go ahead and switch to ruby24 and pyton 3=2E6 across the board=2E >Which I cannot do now till a bunch of ebulids have their targets >increased=2E --=20 Best regards, Micha=C5=82 G=C3=B3rny (by phone) --=20 Best regards, Micha=C5=82 G=C3=B3rny (by phone) --=20 Best regards, Micha=C5=82 G=C3=B3rny (by phone) --=20 Best regards, Micha=C5=82 G=C3=B3rny (by phone) --=20 Best regards, Micha=C5=82 G=C3=B3rny (by phone) --=20 Best regards, Micha=C5=82 G=C3=B3rny (by phone)