From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M8Kit-0004xS-80 for garchives@archives.gentoo.org; Sun, 24 May 2009 20:55:11 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 29347E054F; Sun, 24 May 2009 20:55:10 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E09F5E0550 for ; Sun, 24 May 2009 20:55:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 8386266B0C for ; Sun, 24 May 2009 20:55:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 required=5.5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuqeKteuzsvt for ; Sun, 24 May 2009 20:55:02 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 9A7E4662CD for ; Sun, 24 May 2009 20:54:58 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M8Kid-0006UM-Jk for gentoo-dev@gentoo.org; Sun, 24 May 2009 20:54:55 +0000 Received: from 82.152.195.85 ([82.152.195.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 May 2009 20:54:55 +0000 Received: from slong by 82.152.195.85 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 May 2009 20:54:55 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steven J Long Subject: [gentoo-dev] Re: Re: Re: The fallacies of GLEP55 Date: Sun, 24 May 2009 21:53:34 +0100 Organization: Friendly-Coders Message-ID: <1383824.jKyvaOPduL@news.friendly-coders.info> References: <200905142006.51998.patrick@gentoo.org> <20090514193907.56754ae6@snowcone> <4A0D479F.7040107@gentoo.org> <3957741d4885eeb5a84ffcf262e58344@smtp.hushmail.com> <2682903.cnFe8369yH@news.friendly-coders.info> <20090515201757.4dd324dd@snowmobile> <1876706.o0cNKnX3bN@news.friendly-coders.info> <20090515211303.509104e9@snowmobile> 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: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 82.152.195.85 Sender: news X-Archives-Salt: 6585d9db-c024-427e-846a-333fad3b7f2d X-Archives-Hash: a2f7d23a11bb80684e3c9480657b7576 Ciaran McCreesh wrote: > On Fri, 15 May 2009 21:06:13 +0100 > Steven J Long wrote: >> > Before an ebuild has had its metadata generated, its EAPI is >> > unknown. At this point, the package manager assumes EAPI 0. >> > >> With the format restriction, that everyone last year seemed happy >> with, apart from the few pushing GLEP-55, this isn't an issue. > > The format restriction hasn't been agreed upon, By you. (oh, and your gang.) You're right though, it hasn't been spammed to the list on more occasions than anyone cares to remember, nor has it been pushed up to the Council to vote on, when someone can't convince the rest of the developer community. It just works. > and doesn't solve the whole problem anyway. Only we're not allowed to hear what problem you _think_ exists. You just resort to the Emperor's New Clothes defence. ("I can't explain it, as the fact you don't agree with me, clearly means you're far too stupid to explain it to.") Sorry but those clothes look like rags to me. Shiny you say? Explain it then, as they /still/ look like rags. Or stop wasting everybody's time. Pick one. >> If you have a use-case that actually requires more in a version >> specifier for upstream software, please present it and explain how it >> cannot be represented with the above. > > Go and look at all the ebuilds using MY_PV style hacks. Group these > into "necessary because upstream are being silly" and "we're only doing > this because of some utterly arbitrary rules imposed in the early days > of Gentoo". Most are in the second camp. > Please elucidate the use-case, and how the versions cannot be represented within Gentoo, or within the expanded def'n[2] as you were asked to do. If you're concerned about stupid BASH, perhaps you could direct your energy towards better BASH scripting, and not relying on an eclass to do what #bash beginners learn in their first two weeks. Learning the craft is part of the process. I realise openly sharing knowledge makes it harder for you to hoard it. Deal with it, or don't work in Free software. As for "utterly arbitrary" some of the syntax you've proposed is exactly that. Even worse, it's completely cack-handed. That'd be fine if you didn't also insist that everything you dream up is perfectly worked-out and thought-through from the beginning[1]. The combination is quite dangerous, and were this a professional situation you'd have been out on your ear a long time ago. Not storming back after being 'fired' and emailing the whole company with your rants for the next 3 years. >> In passing, I must express bewildered amusement at the idea of a >> format with an unlimited amount of extensions. > > Not what's being proposed. We're proposing giving each format its own > file extension. > No, you're trying to hijack .ebuild. Even cat-foo/blah-version--EAPI.ebuild would be better than this nonsense. It'd *still* be a bad idea for all the reasons lavajoe (iirc) outlined way back when. I suggest you re-read his post from a long time ago. If you want to do a radically new format, go ahead; no-one's stopping you or holding your work back in any way. The same cannot be said for your continued antics. Oh yeah, .exheres hasn't quite got the same cachet as .ebuild. No satisfaction in it, unlike getting Gentoo to 'submit'. I still haven't seen a version that cannot be handled within the Gentoo schema (and I note you were remarkably silent on suggestions that were put to you[2], as you always are if they didn't come from paludis.) If you're arguing no human input should be required, I think you have a misunderstanding of the user-base. Some of us prefer to know that a human has both tried the ebuild out, and gone through repoman. And that that person takes pride in their name on the commit, and stands by the principle of "you broke it, you fix it." It's called a distribution, not "ciara's collection of stuff scraped from a webservice." [1] 'If it is unwise to trust other people's claims for "one true way", it's even more foolish to believe them about your own designs.' http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2879078 [You seem not to have read this site _at all_. Correct that before posting again.] [2] "Let's just use a prefix instead of a suffix to indicate vcs, keep branch and upstream for dep specification, not filename, to allow inter-repo dependency for overlays for the few cases where it's actually needed, and add debian-style epochs to guarantee future expansion." -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)