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 D422D138247 for ; Mon, 13 Jan 2014 15:22:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BBD10E09EE; Mon, 13 Jan 2014 15:22:46 +0000 (UTC) Received: from juliette.telenet-ops.be (juliette.telenet-ops.be [195.130.137.74]) by pigeon.gentoo.org (Postfix) with ESMTP id 7157AE09E5 for ; Mon, 13 Jan 2014 15:22:44 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by juliette.telenet-ops.be with bizsmtp id DTNj1n00F2khLEN06TNjVN; Mon, 13 Jan 2014 16:22:43 +0100 Date: Mon, 13 Jan 2014 16:21:49 +0100 From: Tom Wijsman To: slong@rathaus.eclipse.co.uk Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [OT] pkgcore bikeshed Message-ID: <20140113162149.4f955b87@TOMWIJ-GENTOO> In-Reply-To: <20140113110210.GA1993@rathaus.eclipse.co.uk> 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> <20140113110210.GA1993@rathaus.eclipse.co.uk> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.22; 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_/=xbiEnFkTC03bxV7m4r16zC"; protocol="application/pgp-signature" X-Archives-Salt: b922d09b-c187-4f35-8581-3d05e16250e3 X-Archives-Hash: ad692adbab585d5551350fb04a82e8d8 --Sig_/=xbiEnFkTC03bxV7m4r16zC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 13 Jan 2014 11:02:10 +0000 "Steven J. Long" wrote: > Yeah but it already outshines under the hood: all you're talking > about is EAPI and radhermit is working on it; pkgcore's response to EAPI 6 is something to hold your breath for. > 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. Yes and no, in the short run I'm going to do some repoman work as to benefit both the QA and Portage teams (and the community as a whole); from that point on I'll try to look at Portage and pkgcore from a broad view (software re-engineering style) to see how I want to continue. As stated in other mails, I'll definitely help keep Portage alive for as long as possible regardless; I will thus have to see if remaining time permits to help out with pkgcore as well. So, in the short run; no, also, I'm devaway for the next two weeks. Like Portage made out a call for people, I think pkgcore should in the near future make out a call for more people; there definitely are some people here and there that have deep interest in it, thus contributions to it might just be waiting around the corner... > Updating both in parallel isn't hard: once pkgcore is up to EAPI-5, > EAPI-6 isn't that much work (mostly bash afair.) Its feature set is unknown afaik, thus it could become easy but just as well become huge; this depends on the approach that the PMS team takes going forward. But for all I know I've seen some things get implemented in Portage, is the same true for pkgcore? > At that point, put portage into feature-freeze, and only bugfix it. Impossible with a new EAPI around the corner. > Call a hiatus on new EAPIs for 6 months and put all effort into > making damn sure pkgcore is a drop-in replacement. This stops the progress of part of the distribution; actually, we've stopped progress on that for quite some time already as we're already running a bit behind on the yearly release of a new EAPI. > > > We could have a technical > > > discussion on the merits of pkgcore vs. portage, but in the end, > > > it's about the users. >=20 > 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. I could indeed conclude the opposite, evening it out; it's pointless to discuss that right now. We're currently discussing the PMs' futures; but we're not discussing "the new package manager default" yet, neither are we discussing a well planned proper migration yet at this time. > > 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) >=20 > 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. With Portage only spending half a minute* a day on it here, /care; and as seen in benchmarks, Portage allows quite some improvements to it. So, if needed, it is certainly possible to bring its time down. * --backtrack=3D0 is my new favorite parameter, don't need more. :) > > [1] /* Side details */ > > In a nutshell we make it possible to track the results of "make > > check" or equivalent test coverage for every source package. > > There's a little work involved for setting up each package, but it > > gives the easy ability to *know* and prove that between xyz > > ${FLAGS} there's no regressions. For example: How do you *know* > > that fftw or ssl is regression free when you enable avx, fma or > > some other higher level of optimization (-O3). By knowing I don't > > mean just result correctness, but also potentially runtime > > performance, code size and potentially compile times. (If those are > > things you care about) >=20 > 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 Now that I read this again: Performance, size and compile times mean nothing if you don't get a correct result; it all gets funny when the scrollbar of your browser breaks just because one of its many deep dependencies was built with -Ofast, then that small bit of extra performance can be laughed at. And yeah, searching that dependency is also a lot of fun; which means you'll want to recompile libraries with -O2 again until you have found it, unless you want to spend days figuring it out. And for this last thing, it's handy you can grep flags in the /var/db/pkg/. At which point you can be lucky it isn't done by some package that has bad QA and has overridden CFLAGS or something like that. --=20 With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D --Sig_/=xbiEnFkTC03bxV7m4r16zC Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJS1ASNAAoJEJWyH81tNOV9y9wH/jpPMSCm0sKEwd74eBqL4XiY //UG9nMP/uF1XtsKnMiMw8rB+PlLbtLqEeZvEPFcf+2Gth+E8Lj+zht4AscOkr/c GXVQyecxeyOVdWfw8w8rDEgCDG5zhhS+NdWzp7mflm91ML69hgMgKSzZDweo7SYn 9jt1c3Q3sEkaZJ7SFreK1Y+2WU2nHVrZogT9SUKBmvt1O+8ysVU9HsE/DKmlyqQo T1kZpN17KJQQDee/t3W8ZL+r0v2dbkGgocBB0FyE8lt+oEVZFaqZGCNrXrEik1Dx o9t/IGuWs9OHO1wHRLdyI13eOXmXLNVmtr2XcbT2e+8//d/6ZrfvDC6zruXJPcI= =OQi4 -----END PGP SIGNATURE----- --Sig_/=xbiEnFkTC03bxV7m4r16zC--