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 <gentoo-dev+bounces-34501-garchives=archives.gentoo.org@lists.gentoo.org>) id 1LbwBt-0004Ur-NU for garchives@archives.gentoo.org; Tue, 24 Feb 2009 12:15:13 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0932DE03DB; Tue, 24 Feb 2009 12:15:12 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id BA342E03DB for <gentoo-dev@lists.gentoo.org>; Tue, 24 Feb 2009 12:15:11 +0000 (UTC) Received: from [192.168.0.92] (83-103-77-215.ip.fastwebnet.it [83.103.77.215]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id B3FAB64865 for <gentoo-dev@lists.gentoo.org>; Tue, 24 Feb 2009 12:15:10 +0000 (UTC) Message-ID: <49A3E4CD.1020507@gentoo.org> Date: Tue, 24 Feb 2009 13:15:09 +0100 From: Luca Barbato <lu_zero@gentoo.org> User-Agent: Thunderbird 2.0.0.18 (X11/20081205) Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> 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] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) 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> <49A3AAA1.6080207@gentoo.org> <49A3B947.2020907@gentoo.org> <49A3D0F6.6080307@gentoo.org> In-Reply-To: <49A3D0F6.6080307@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 08c89c08-29f2-4a41-a67c-9cac7e2fa49b X-Archives-Hash: 3f969d42d41700b0b56124f627cf7ec8 Alistair Bush wrote: > > Luca Barbato wrote: >> Alistair Bush wrote: >>> I just don't think those numbers tell us anything and that should be >>> obvious from anyone who has read GLEP 55[1], we ain't really attempting >>> to solve a problem that exists within the tree currently (well the bash >>> issue does, in a way ). We are trying to solve issues that ware stopping >>> the "tree" moving forward. Lets evaluate GLEP 55 in the problems it is >>> attempting to solve. >> I'm afraid you missed the whole point... >> >> - what is in the proposal is a solution looking for a problem: nobody >> updated the glep with the required sections, nobody put up a list of >> bugs/rfe from bugzilla it helps to solve. Vague "leading to the future >> change" declaration aren't what I'd expect. >> > > So im mean't to start committing ebuilds into the tree that expect a > certain unimplemented functionality, only to file bugs against portage > for it not supporting them? Apparently you missed rfe or that it does mean =\ > Plus we already know of at least one case where we will encounter a > problem in the future, why? because we have already. > Not sure if there is a open bug about it tho. Do you know that "a problem" means nothing, bug #number means something? Do you know that improvement and enhancement can be requested on bugzilla as well? > This actually eats at me, your basically saying GLEP's should only be > reactive. Why don't we all just roll over and die. I'm afraid you are getting quite emotional for no reason. > I have already considered the problems, and believe GLEP 55 is the > **best** solution to them. Is it perfect, no. But I have yet to see > anything better. YOU, other did and consider what is proposed on that trash. Mediation is needed apparently. What is sure is that the glep proposal is lacking lots of details and apparently none of the proponents are even willing to try to cope with that. > Yes exactly, you need to know the EAPI before you __parse__ the ebuild. You have to extract the eapi before doing the parsing the eapi defines, but you can parse the ebuild just to get the eapi and then do something or nothing depending on that value... > 1) How about in a flat txt file: That would become a developers > nightmare. > 2) In an xml file. Package managers would have to support xml. Not > the best thing in the world. also could be a nightmare, adding an entry > for every ebuild. > 3) As an xattr. Well this idea is novel. I bet it would make the tree > nice and stable too. Lets not forget how annoying it will be for devs. > 4) Parsing the ebuild. But what are we parsing?, lets not limit > ourselves to bash, we might want to change languages completely. If it > is bash, what version, what if EAPI is set multiple times, what if its > set in an eclass. "What if" is exactly something you cannot use, it's a slippery slope that leads to qbits frozen objects from the outher space or other insane stuff that may or may not happen. > 5) Mmmmm...On the file name sounds like a good idea. especially as an > extension. provides information to a package manager, person, > script/program without them needing to open anything. identifies the > contents just like .txt, .c, .o, .jpeg, etc So for normal multimedia file I'd have to have "myfile.mov-aac-h264-ass" as extension? strange, mplayer is perfectly fine even if it is called "myfile" and file(1) usually can tell me what's inside it in term of codec and sometimes even it's params. >> - Extracting such information could have different costs depending on >> where to place it. > > I believe it being on the filename would be the least costly, in terms > of processor/io at least. try yourself, I did and that's what I found regarding the case of cache regen (that, as I wrote earlier, is the interesting case) is in one of the previous emails as well... btw it's also quite easy plant both proposals in portage and see what happen if you really like, but I preferred give something everybody can try in bash. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero