From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 2D3AE138010 for ; Sun, 16 Sep 2012 07:24:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1F762E0525; Sun, 16 Sep 2012 07:24:10 +0000 (UTC) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by pigeon.gentoo.org (Postfix) with ESMTP id C580AE0525 for ; Sun, 16 Sep 2012 07:24:09 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so8271833pbb.40 for ; Sun, 16 Sep 2012 00:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=xKyVAttd42M1yfBepS5g90k3FmKNYG6MueAXf8YlCrc=; b=FHea3EWMzZXTdPCPMUTNbaDijeKn8Qh33tp3Cw5+uzzyLZGMAaZe8wLDV6uC8yFT56 nSbZepWrl8OLCxq0LpFfh7lnmyEpgLPgiIshC8NprefY2eJ/FwnRiOIV96BUCZNLTYmy svDUpR4DipG+7hOEkxPPj2wlQFhN4uRhlWNrVMOG/MWeug1al6hQYP+pRjrU9MvzWtXp f1/QaLnFf3RmWxnLxIUJwpcZWfkJFM69J+PWY2GDBs1ccK2iWo4Qm5RuUzwL68aaQhyp SH/Mi32JGFK2kJQgtdImbFJ5JhFEfXZRdbldIcLB5yQIFhZlfOMcFTTw/dxoYXQ8n/+l Hw9w== Received: by 10.68.222.42 with SMTP id qj10mr14443986pbc.117.1347780248836; Sun, 16 Sep 2012 00:24:08 -0700 (PDT) Received: from smtp.gmail.com:587 (74-95-192-101-SFBA.hfc.comcastbusiness.net. [74.95.192.101]) by mx.google.com with ESMTPS id gh7sm4521208pbc.29.2012.09.16.00.24.06 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Sep 2012 00:24:08 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Sun, 16 Sep 2012 00:24:18 -0700 Date: Sun, 16 Sep 2012 00:24:18 -0700 From: Brian Harring To: gentoo-pms@lists.gentoo.org Subject: Re: [gentoo-pms] Re: [PATCH] Allocate __* for package manager internals, blacklist it for ebuilds. Message-ID: <20120916072418.GJ28593@localhost> References: <1347327593%2d1144-1-git-send-email-ferringb@gmail.com> <20565.30069.397545.214809@a1i15.kph.uni-mainz.de> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Package Manager Specification discussions X-BeenThere: gentoo-pms@gentoo.org X-BeenThere: gentoo-pms@lists.gentoo.org Reply-To: gentoo-pms@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20565.30069.397545.214809@a1i15.kph.uni-mainz.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 7dc5072d-a74a-410b-90d4-e7622155c37d X-Archives-Hash: 7c06bb06af480cb12ea4f87f48b603ad On Sun, Sep 16, 2012 at 08:45:09AM +0200, Ulrich Mueller wrote: > >>>>> On Tue, 11 Sep 2012, Brian Harring wrote: > > > To varying degrees, existing PMs use names that aren't prefixed in > > some fashion indicating it's an internal- the end result being > > ebuilds/eclasses that rely on a PM internal (both bad for alternate > > PMs, and bad should that internal change). > > > Further, the lack of a standardized namespace for the PMs internals > > means QA tools must maintain their own lists. As such, allocate __* > > for the PM to use for it's internal functionality and variables. > > We already have a section "Reserved Commands and Variables", and I > think that the information should be added there. See one-line patch > below. I'd frankly rather it in both locations. Ebuild devs are more likely to read the sections I tagged w/ this info, imo. > > I also wonder about the rest of the list: "abort", "dyn", "ebuild", > "hook", "paludis", "portage", "prep". The annoying thing about that list is that 'prep' has a few scenarios where it has to be used to get things done. It would be useful if rather than PMS stating "that's naughty, and screw you, we don't need to provide a solution to replace it", we documented some form of a solution. That's an age old bitching/rant point from when the doc was first written. We *really* need to clean that shit out, it makes the spec worthless in spots. Either way, that list isn't particularly accurate; the real problem aren't those, the problem is random bits of functionality laced into the env that are easy to mistake for eclass functionality- paludis in particular doesn't protect itself all that much. This is pretty much why I went the nuclear route; everything in __* unless it's explicitly exempted to keep existing behaviour working (in which case, we need to document or find solutions for those cases rather than pretend they don't exist). > [prep] occurs in > src_prepare, so forbidding it in ebuilds doesn't look so reasonable. ;-) Nice. :) > Some of the others (like "dyn" and "hook") are used in eclasses. > Should repoman enforce that they're not used? No. dyn_ is trying to block invocation of dyn_${phase}, dyn_preinst for example; it's a bit of a worthless proscribement due to the fact an ebuild can't sanely invoke the dyn_* functionality of portage (multilib attempts notwith standing). Honestly, I strongly think we should just go the route I proposed with this patch. For pkgcore, it's completely compliant for it's internal functions, and for it's variables most are prefixed w/ PKGCORE_; moving them to __ I'll do sometime this week. For portage, I moved 95% of the functionality; offhand the only thing left was register_{die,success}_hook which I'll get shortly. For portage, the environment needs work- I'd strongly appreciate it if you took care of that Zac since it requires touching both python and bash, and 1) portage code is fairly dense, meaning it's likely I'd make a bug or two, 2) I didn't make that mess (the cleaning of it is part of where pkgcore originated from) :) If required, with a fair amount of bitching during it I will do portages env cleaning. As for paludis, ciaran or dleverton should be able to sort their end of it. ~harring