From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Lc1xD-0003R2-B8 for garchives@archives.gentoo.org; Tue, 24 Feb 2009 18:24:27 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1BCC6E067D; Tue, 24 Feb 2009 18:24:25 +0000 (UTC) Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.153]) by pigeon.gentoo.org (Postfix) with ESMTP id E7575E067D for ; Tue, 24 Feb 2009 18:24:24 +0000 (UTC) Received: by yx-out-1718.google.com with SMTP id 3so1067999yxi.46 for ; Tue, 24 Feb 2009 10:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=+w9fa69Nmgi4LpKYbvqyNaD4P5D/SlHdlGYO0pBQLZk=; b=Hw0Dmn6JNYh0CYpFAvrsT495VAcumD5JTK7gEe+FEzx6m/gbjt7JEhTPpNjhVi/U/A e9F2SOj8klVLNzbjrIw3/q3YQW4OottW1Brh3Vk9aq2BqunqP6TBLF0m4KTz/ifTt1bS QmPNgMNOn4NcSgHclk6pxK6cg/O65znIuy2JA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=bBhBSwcfh/wcgWdJIFCeMLCx4JkEwNoCfJOf4HSV+Z8sqFuVeDLQb2OJe7SrPSUSQD ODSQ29gPflUdP1sORQVnA+f/+mVpZiYxZDIAAojmi5AYT5tsVLvltRrqTCve1itQ1mP3 nvkAs6uMksRT1ApbHZPf1Jfq8fX28zkXbPcs4= Received: by 10.151.47.7 with SMTP id z7mr1405ybj.87.1235499864447; Tue, 24 Feb 2009 10:24:24 -0800 (PST) Received: from snowcone (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id e23sm19711257ugd.54.2009.02.24.10.24.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 10:24:23 -0800 (PST) Date: Tue, 24 Feb 2009 18:24:16 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) Message-ID: <20090224182416.3db4f60f@snowcone> In-Reply-To: <49A42B86.9010903@gentoo.org> References: <1234257125.18160.2016.camel@localhost> <1234450419.20950.2.camel@localhost> <20090212160045.GB3642@comet> <20090212161644.GD3642@comet> <20090212162103.256b003f@snowcone> <20090212171055.GA3652@comet> <20090212172109.778fb268@snowcone> <20090212173743.GD3652@comet> <20090212180350.0d9a9df5@snowcone> <1235037961.13198.779.camel@localhost> <20090219125124.33eaa66c@snowcone> <1235077892.13198.1923.camel@localhost> <20090222171658.278ae167@halo.dirtyepic.sk.ca> <49A1E1CB.1000806@gentoo.org> <20090222234800.29d64b8d@snowcone> <49A206A7.3050604@gentoo.org> <49A39CE7.4010201@gentoo.org> <20090224141912.0a666a17@snowcone> <49A41A8C.1060002@gentoo.org> <20090224161449.07bc580a@snowcone> <49A42B86.9010903@gentoo.org> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; 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; boundary="Sig_/xxN1HmwazIUiU9Es0EXG=P3"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 08389fd4-542b-4995-928c-737216fbdc7a X-Archives-Hash: 5a142aee67e6acc1b270698c87306ec1 --Sig_/xxN1HmwazIUiU9Es0EXG=P3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 24 Feb 2009 18:16:54 +0100 Luca Barbato wrote: > > You're doubling the number of files that have to be read for an > > operation that's almost purely i/o bound. On top of that, you're > > introducing a whole bunch of disk seeks in what's otherwise a nice > > linear operation. >=20 > I see words, not numbers. Number: double. That's a '2 times'. > >>> That is not how metadata checks work. > >> Explain how they work, regen works that way... > >=20 > > If metadata is valid, ebuilds aren't opened at all. An optimal > > implementation can slurp up the entire directory in one go and then > > start pulling out cache entries as it needs them, not having to go > > back to the ebuild directory or read its contents at all. Then it > > can open and read cache files in a carefully selected order to > > avoid having to do any more opens than necessary. >=20 > So? if the cache is valid then you don't have to source them at all. > If you have to regen it, well you have to read everything. You don't know whether the cache is valid until you know the EAPI. It only works currently because EAPIs don't change inherit behaviour. > >>> By parsing the ebuilds you're talking doubling the number of file > >>> reads required to get the job done, and massively increasing the > >>> number of seeks required. > >> Apparently it doesn't impact anything. > >=20 > > Please show the patch you created (for Paludis, since Portage > > doesn't yet do a lot of the optimisations it could here) that > > demonstrates this. >=20 > Paludis isn't portage. So you have patches for Portage? Please show them. > >>> But that isn't even the main issue. The main issue is that even if > >>> you retroactively pretend that all ebuilds are in a format they're > >>> not, and ignore the breakage, and then wait for a year for package > >>> managers to try to parse your new format, you *still* can't change > >>> name or versioning rules. > >> why? when portage would breanch if I put an ebuild with a wacky > >> version AND there is a valid cache for that telling its eapi 99 ? > > > > Because it has to parse that version. Also, the package manager > > can't tell whether or not a cache entry is valid if it doesn't > > recognise the EAPI in the cache entry. >=20 > unknown isn't unsupported? Huh? Please explain what you mean. > >>> Again, these are all things that have been discussed at length > >>> previously. Please either come up with a legitimate technical > >>> objection, or admit that you've seen the light. > >> the glep doesn't show any of those nor reference to it, as I said=20 > >> before, do your homework and probably more people will be happier > >> with your proposals. > >=20 > > Why should it? The C++ standard doesn't explain why you should use > > it instead of Java... >=20 > In fact many people do wonderful things with java and many more just > do over engineered mess with C++? Your trolling is going rapidly downhill. --=20 Ciaran McCreesh --Sig_/xxN1HmwazIUiU9Es0EXG=P3 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmkO1MACgkQ96zL6DUtXhHhQACg4OFBi0yWPcM1BO+uGRKwK4nT GP8AoJfLE49g5hP1l22SL5bpNwFcQNbS =YKk6 -----END PGP SIGNATURE----- --Sig_/xxN1HmwazIUiU9Es0EXG=P3--