From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7142 invoked by uid 1002); 7 Dec 2003 03:10:56 -0600 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 24199 invoked from network); 7 Dec 2003 03:10:56 -0600 User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Sun, 07 Dec 2003 01:11:00 -0800 From: Kapil Thangavelu To: Message-ID: In-Reply-To: <1070782855.6073.441.camel@ht.gentoo.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [gentoo-portage-dev] portage-ng concurse entry Was: Updated Portage project page X-Archives-Salt: 1b0dee90-d39a-436e-befc-ddf9466afb7b X-Archives-Hash: d7e2c10b6275fd098063f4145df14c5d are we at the stage yet, where some structured metadata representation outside of the ebuild will be used ? incidentally the mailing list manager isn't honoring requests for archives/indexes... so, apologies in advance if this has already been discussed/decided. -k On 12/6/03 11:40 PM, "Daniel Robbins" wrote: > On Sat, 2003-12-06 at 19:39, George Shapovalov wrote: >> Hm, isn't it a bit too late to change ebuild format, with us sitting on 7000+ >> ebuilds? The only reasonable way to do so is to make it structurally >> compatible and create a converter tool. > > It would be very difficult to get good results from a converter tool, > due to the many complexities of ebuild parsing. > >> But then I don't really see the problem with present format. > > You just explained how much of a chore it would be to convert from > ebuild to something else. Doesn't this point to a weakness in the syntax > of ebuilds themselves? I mean, if they were more formally defined, they > could be converted to XML or anything else without much effort. > >> bash involvment >> is really necessary only during the pkg_* and src_* steps, when a lot of >> other stuff is going to happen anyway, so this is hardly a bottleneck. > > This isn't an informed comment :) Portage depends on bash for extraction > of metadata as well. Extraction of metadata is *the* Portage bottleneck. > >> To get >> definitions of various vars and dependency information out is trivial and can >> be done in anything. That bash is involved in this step at present is >> unfortunate, but there were reasons for it and it definitely may be undone >> even for the present portage. > > If it were trivial we would have done it already. The only way to "undo" > the dependence on bash is to make seemingly arbitrary rules of what is > legal and not legal to type inside ebuilds. This leads to a lot of > strange rules (such as rules about where you can and can't use variable > expansion, and where you can and can't use bash conditionals) and makes > ebuild-writing a tricky process. We already have some of these rules in > effect, and it makes ebuild-writing a bit trickier than it should be. > > We don't want ebuild-writing to be tricky, so the solution is to > architect a way to represent ebuild data in a way that is more useful to > portage-ng and more natural for ebuild-ng writers. > > Regards, > > Daniel > -- gentoo-portage-dev@gentoo.org mailing list