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 1LbcH3-00072c-Q0 for garchives@archives.gentoo.org; Mon, 23 Feb 2009 14:59:14 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6A228E04B2; Mon, 23 Feb 2009 14:59:12 +0000 (UTC) Received: from mail-fx0-f161.google.com (mail-fx0-f161.google.com [209.85.220.161]) by pigeon.gentoo.org (Postfix) with ESMTP id EB7FBE04AF; Mon, 23 Feb 2009 14:59:11 +0000 (UTC) Received: by fxm5 with SMTP id 5so1797406fxm.10 for ; Mon, 23 Feb 2009 06:59:11 -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:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=US4QanngY+HhQ3JQAWmBWQ0hVIkwa1n3Khnkhyz2lac=; b=gHwBuo+KHM/ftJlrUIqVgXSto9taqoAJCxGHmanL9uKDr4+MHwQC7KDLWavaHYfzPr bYx60AsjHvvo5MlJ1YPJwoor9AQGzXsGKtgHJEt9dnMZ4aq2robLMXwNY9krww71ZF3m Ls1zwvPtU2DQ0zi+k1l6BngrOaeJ9GojOulrA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=sLb+17Dzf4YLfsbVLD33d6md2rvh6TZUfP3gO3o0vLCSFowOnxSh92MU8CJSsGMkk4 Bep8Fd53fIwHv5JHgPmTDNNtpD8uqFdDKrs3QAtm3FKbX71Ack470EjqgIqKdVI7N6z+ utt3HxJxI5P4GsPL0NjU7mhJP21iIrFtIpVWU= Received: by 10.103.1.5 with SMTP id d5mr1291733mui.29.1235401151140; Mon, 23 Feb 2009 06:59:11 -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 k30sm16121691ugc.29.2009.02.23.06.59.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 06:59:10 -0800 (PST) Date: Mon, 23 Feb 2009 14:59:02 +0000 From: Ciaran McCreesh To: Luca Barbato Cc: gentoo-council@lists.gentoo.org, gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) Message-ID: <20090223145902.0207a965@snowcone> In-Reply-To: <49A2B6C0.1070900@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> <20090223135702.3d593d3f@snowcone> <49A2B6C0.1070900@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_/fge+dPF=X0VkN=FQFVdfQ5d"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 576f9d8f-3817-411f-855d-c815b0e4546b X-Archives-Hash: e4707871708fbfc898b7c9be069ef368 --Sig_/fge+dPF=X0VkN=FQFVdfQ5d Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 23 Feb 2009 15:46:24 +0100 Luca Barbato wrote: > >> Apparently we do not have any issue... > >=20 > > ...assuming the metadata cache is valid. That isn't always the case. >=20 > When it isn't? Every now and again (probably after someone changes eutils...), rsync mirrors end up shipping a load of stale metadata for parts of the tree. Portage users probably don't notice, since it just causes a slowdown. > disable overlays to UPGRADE to the new portage. Not rocket science... No no. You're forcing people to switch to ~arch to be able to use overlays. > >> In this case we have a problem if the source step is a single one,=20 > >> portage won't know in advance how to behave. > >> > >> So the first step has to be split in two: > >> - first portage discovers which is the eapi version > >=20 > > ...which it can't do, because it doesn't know the EAPI. >=20 > If you are generating the cache you must have a way to know it... No, we don't. That's the entire frickin' point of GLEP 55, and one that you would do well to understand fully before commenting further. The way we generate metadata now is massively horrible, and only works because there aren't any serious global scope differences between EAPIs. We can't make any global scope changes to future EAPIs because it breaks current metadata generation. Right now it's safe to pretend EAPI 0 until the real EAPI is worked out, but that won't hold in the future -- as soon as global scope changes come along, there's no safe EAPI that can be assumed, even if we didn't have to worry about breaking existing package managers. > >> The problem is that right now sourcing is done by having an > >> instructed bash. So the simplest way to get the first step done is > >> parsing the ebuild file with something different like file(1) and > >> then instruct bash and do the parsing. > >=20 > > file(1) can't parse ebuilds. >=20 > file parses quite well avi and mov, ebuild will be anytime more > complex than that right? It's already *way* more complicated than that. Extracting metadata requires a full bash 3 implementation along with a considerable amount of supporting code. > Anyway it isn't a problem since the version of portage doing the work > is supposed to be up to date, if isn't it will be updated first using > the normal user workflow that has already been covered by the cache. Most users don't run ~arch, and do use overlays. So no, this will affect normal user workflow. > > Only an ebuild implementation can parse > > ebuilds, and only if it already knows the EAPI. >=20 > That is always the case since you are adding an ebuild and you are=20 > supposed to have an up to date portage in order to do that. Again, you're not getting it. Doesn't matter how up to date your package manager is. You can't find out the EAPI unless you already know the EAPI. > >> What is proposed in glep-55 seems to aim to solve both issues at > >> the same time (it isn't stated) by switching file extension every > >> time the eapi is changed. This is slightly against the principle > >> of the least surprise and apparently is disliked by enough people > >> to lead the situation to be discussed in the council. > >=20 > > There's no surprise at all. It's extremely clear. >=20 > Not that much. How is '.ebuild-3' being used to specify version 3 of the ebuild format in the least bit surprising? --=20 Ciaran McCreesh --Sig_/fge+dPF=X0VkN=FQFVdfQ5d Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmiubkACgkQ96zL6DUtXhHqGwCgmxtPnBdhP08aT4cry+sA2hkn 8FYAmwTAUqC2/chF5W3G7s42NXH5jyPu =ak9c -----END PGP SIGNATURE----- --Sig_/fge+dPF=X0VkN=FQFVdfQ5d--