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 1LdWBI-000141-MH for garchives@archives.gentoo.org; Sat, 28 Feb 2009 20:53:08 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A190DE0281; Sat, 28 Feb 2009 20:53:06 +0000 (UTC) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by pigeon.gentoo.org (Postfix) with ESMTP id 6DD74E0281 for ; Sat, 28 Feb 2009 20:53:06 +0000 (UTC) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA03.westchester.pa.mail.comcast.net with comcast id MYrY1b00416LCl053Yt7ku; Sat, 28 Feb 2009 20:53:07 +0000 Received: from [192.168.1.13] ([69.140.18.238]) by OMTA06.westchester.pa.mail.comcast.net with comcast id MYt61b00E58Be2l3SYt7cT; Sat, 28 Feb 2009 20:53:07 +0000 Message-ID: <49A9A422.5040009@gentoo.org> Date: Sat, 28 Feb 2009 15:52:50 -0500 From: Kumba User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives References: <49A472E3.1010204@gentoo.org> <49A608CA.1040104@gentoo.org> In-Reply-To: <49A608CA.1040104@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 92c853b6-3c1f-43d1-97d1-213ae3e0d57b X-Archives-Hash: d2cf9f6879adfcdec8857154ed10abc0 Kumba wrote: > > I was talking to Alec last night in -dev (yes, I'm still alive), and I > tossed out the idea of using metadata.xml instead of mangling the ebuild > filename or even sticking it as the first line in the ebuild (as a > hashbang or something gentoo-specific, for example). Fleshing out more (And to solicit more thought on this idea -- insane?). Using mips-sources as an example: # ls -l /usr/portage/sys-kernel/mips-sources/*.ebuild total 116K -rw-r--r-- 1 root root 19K Jan 9 04:10 mips-sources-2.6.20.18.ebuild -rw-r--r-- 1 root root 18K Jan 9 04:10 mips-sources-2.6.27.10.ebuild -rw-r--r-- 1 root root 18K Feb 23 16:43 mips-sources-2.6.28.7.ebuild Would, to specify them as EAPI=2 in metadata.xml, be encoded as (just an example -- suggest other formats): pv = specifies the package version ver = eapi version. Better names for these values? Suggest! I didn't want to re-use 'api' or anything. Maybe ? Anyways, after commiting to gentoo-x86 CVS, a backend script, similar to or the same as whatever parses out the tags will run and extract this data, and update /usr/portage/profiles/eapi.list (example name). /usr/portage/profiles/eapi.list will resemble something like this: sys-kernel/mips-sources-2.6.20.18:2 sys-kernel/mips-sources-2.6.27.10:2 sys-kernel/mips-sources-2.6.28.7:2 Upon installing the package by whatever package manager (portage is my example), it will process this eapi.list, much like it does use.desc and use.local.desc, and therefore know all it needs to know, then it can source the ebuild and use whatever logic it needs to follow that specific EAPI. That is if my assumption is correct that the usr.desc/use.local.desc stuff is parsed prior to the ebuild itself being sourced. If not, well, I dunno then. I'm guessing here. The pros of this that I can see: - No changes to the current filename structure. Things stay the name, CVS history is retained because existing files aren't renamed (we're not on git just yet). - No special markers, comments, or bash vars inside the ebuild. Covers some of the other cons that were presented. - Older package managers won't read eapi.list, and can resume their default behavior of EAPI=0. Allows backwards compatibility. - Newer package managers will assume a non-entry in eapi.list to equal EAPI=0, so there won't be a big rush to update every package/metadata in the tree. Allows for slow, controlled adoption. Cons that I can see: - metadata.xml gets updated more frequently because specific versions can get cited (workaround idea, see below) - Backend has to do extra work (minimal? Can infra comment on the feasibility of this?) I'm suggesting this mostly because both ideas of embedding the EAPI value in the filename and inside the ebuild seem like ugly workarounds. Others are also noting other problems with both of these approaches. EAPI also feels more like a metadata-type thing anyways. I mean, if we're already storing local USE flags in it, why not EAPI stuff? I'm a tad behind on the whole discussion, I know, but why not toss the idea out there. Some other thoughts on the first con, of metadata being updated more frequently -- we allow the use of wildcards: Would mark every ebuild in the directory for a given EAPI value (EAPI=2 in this case) Marks every ebuild version lower than 2.6 as EAPI=1. Basically, the wildcard modifiers Portage currently understands would apply. Or we could limit it to a subset of these wildcards (say, *, <, >, <=, and >=). Obviously, tools like repoman would need to be able to read metadata as well (can it? I don't know) and make sure that the versions specified in the 'pv' value exist in the directory before commit. Either by specific value or by expanding the wildcard notation and then cross-referencing the files listed in the directory and with CVS/git/whatever. But to be honest, none of the ideas, even my own, seems like "the best" idea. I think of mine as less intrusive to the tree and less visible to the end users and the package managers, but maybe there's other options not thought of yet? -- Joshua Kinard Gentoo/MIPS kumba@gentoo.org "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic