From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E8E14138247 for ; Mon, 13 Jan 2014 10:50:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 693E7E0A64; Mon, 13 Jan 2014 10:50:35 +0000 (UTC) Received: from smtpout.karoo.kcom.com (smtpout.karoo.kcom.com [212.50.160.34]) by pigeon.gentoo.org (Postfix) with ESMTP id 4F171E09DF for ; Mon, 13 Jan 2014 10:50:33 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,652,1384300800"; d="scan'208";a="57671846" Received: from unknown (HELO rathaus.eclipse.co.uk) ([91.85.38.254]) by smtpout.karoo.kcom.com with ESMTP; 13 Jan 2014 10:50:33 +0000 Date: Mon, 13 Jan 2014 11:02:10 +0000 From: "Steven J. Long" To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: [OT] pkgcore bikeshed Message-ID: <20140113110210.GA1993@rathaus.eclipse.co.uk> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <1388986435.17870.49.camel@big_daddy.dol-sen.ca> <1389582464.7103.185.camel@big_daddy.dol-sen.ca> <20140113083917.5427344.53422.41690@pathscale.com> <52D3A71F.9040602@plaimi.net> <52D3AEB9.7080500@pathscale.com> 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-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <52D3AEB9.7080500@pathscale.com> X-Archives-Salt: 4953846a-5bcf-4fff-964c-68424421a6c6 X-Archives-Hash: c612c832b7afa2229aabacf94cf877e1 On Mon, Jan 13, 2014 at 04:15:37PM +0700, "C. Bergstr=C3=B6m" wrote: > On 01/13/14 03:43 PM, Alexander Berntsen wrote: > > Realistically, we have to keep updating them both in parallel. pkgcore > > needs to be brought up to portage-level functionality, Yeah but it already outshines under the hood: all you're talking about is EAPI and radhermit is working on it; I'm sure he and dol-sen would be happy for more help as well, so long as it's supportive. ISTR TomWij is involved too. Updating both in parallel isn't hard: once pkgcore is up to EAPI-5, EAPI-6 isn't that much work (mostly bash afair.) At that point, put portage into feature-freeze, and only bugfix it. Call a hiatus on new EAPIs for 6 months and put all effort into making damn sure pkgcore is a drop-in replacement. There's certainly enough devs to do that, and definitely enough interest in finally moving to portage-NG. > > and we need to keep fixing portage bugs for its many users. Sure. > > We could have a technical > > discussion on the merits of pkgcore vs. portage, but in the end, it's > > about the users. I don't think anyone who's serious can come down on any side but pkgcore in that debate, so I agree we skip that discussion. You won't get any disagreement from me on your last point. > > For the record, I would be very happy if you hacked on pkgcore. Just > > as happy as if you hacked on portage, even. So please do. :-) Good good :-) > We can blah blah about performance of resolving package dependencies > all day long, but it's clearly not a game changer feature for users. > (or they just don't know) They just don't know: and it really is a game-changer, once you've tried it. We must be able to finally deliver pkgcore speed, 5 years after the event. > Long term the API to pkgcore could be beneficial, but again I'm not sure > it's a game changer for users. Doesn't matter: it's good to have something the devs can get hyped about to= o. snakeoil is a lovely bit of code. > [1] /* Side details */ > In a nutshell we make it possible to track the results of "make check"=20 > or equivalent test coverage for every source package. There's a little=20 > work involved for setting up each package, but it gives the easy ability= =20 > to *know* and prove that between xyz ${FLAGS} there's no regressions.=20 > For example: How do you *know* that fftw or ssl is regression free when= =20 > you enable avx, fma or some other higher level of optimization (-O3). By= =20 > knowing I don't mean just result correctness, but also potentially=20 > runtime performance, code size and potentially compile times. (If those= =20 > are things you care about) OFC they are, or we wouldn't be using Gentoo ;) And that does sound like an interesting project, of wider interest to the community. (hint hint;) =20 --=20 #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)