[gentoo-pms] Re: [PATCH] Allocate __* for package manager internals, blacklist it for ebuilds.

[gentoo-pms] Re: [PATCH] Allocate __* for package manager internals, blacklist it for ebuilds.

[Ulrich Mueller]

>>>>> 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 also wonder about the rest of the list: "abort", "dyn", "ebuild",
"hook", "paludis", "portage", "prep". The last one occurs in
src_prepare, so forbidding it in ebuilds doesn't look so reasonable. ;-)

Some of the others (like "dyn" and "hook") are used in eclasses.
Should repoman enforce that they're not used?

Ulrich


From d80c7b7933e07aeb9f55543e15839230f5ca005f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= <ulm@gentoo.org>
Date: Sun, 16 Sep 2012 08:25:15 +0200
Subject: [PATCH] Strings beginning with two underscores are reserved.

---
 pkg-mgr-commands.tex | 1 +
 1 file changed, 1 insertion(+)

diff --git a/pkg-mgr-commands.tex b/pkg-mgr-commands.tex
index 772613e..06856e2 100644
--- a/pkg-mgr-commands.tex
+++ b/pkg-mgr-commands.tex
@@ -858,6 +858,7 @@ strings (ignoring case) are reserved for package manager use and may not be used
 ebuilds:
 
 \begin{compactitem}
+\item \t{\_\_} (two underscores) at beginning of string
 \item \t{abort}
 \item \t{dyn}
 \item \t{ebuild}
-- 
1.7.12

Re: [gentoo-pms] Re: [PATCH] Allocate __* for package manager internals, blacklist it for ebuilds.

[Brian Harring]

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

Re: [gentoo-pms] Re: [PATCH] Allocate __* for package manager internals, blacklist it for ebuilds.

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

On Sun, 16 Sep 2012 00:24:18 -0700
Brian Harring <ferringb@gmail.com> wrote:
> The annoying thing about that list is that 'prep' has a few scenarios 
> where it has to be used to get things done.

The thing about the prep* functions is that no-one seems willing to lock
down their behaviour.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-pms] Re: [PATCH] Allocate __* for package manager internals, blacklist it for ebuilds.

[Ulrich Mueller]

>>>>> On Sun, 16 Sep 2012, Brian Harring wrote:

> I'd frankly rather it in both locations.  Ebuild devs are more likely 
> to read the sections I tagged w/ this info, imo.

I doubt that many ebuild devs will consult the PMS to find out about
reserved names.

The only way to ensure that __* names are not used in ebuilds is to
enforce it with repoman. And maybe add a note in the devmanual.

Ulrich

Re: [gentoo-pms] Re: [PATCH] Allocate __* for package manager internals, blacklist it for ebuilds.

[Brian Harring]

On Sun, Sep 16, 2012 at 06:14:03PM +0200, Ulrich Mueller wrote:
> >>>>> On Sun, 16 Sep 2012, Brian Harring wrote:
> 
> > I'd frankly rather it in both locations.  Ebuild devs are more likely 
> > to read the sections I tagged w/ this info, imo.
> 
> I doubt that many ebuild devs will consult the PMS to find out about
> reserved names.
> 
> The only way to ensure that __* names are not used in ebuilds is to
> enforce it with repoman. And maybe add a note in the devmanual.

Multiple fronts are required, yes.  We still need the hard rule 
however ;)

So... this getting added into the list, or what? :)
~harring

Re: [gentoo-pms] Re: [PATCH] Allocate __* for package manager internals, blacklist it for ebuilds.

[Ulrich Mueller]

>>>>> On Tue, 18 Sep 2012, Brian Harring wrote:

>> The only way to ensure that __* names are not used in ebuilds is to
>> enforce it with repoman. And maybe add a note in the devmanual.

> Multiple fronts are required, yes.  We still need the hard rule 
> however ;)

> So... this getting added into the list, or what? :)

I've already added it to the list of reserved variables:
<http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=bf47c32d509d56a35b224acd51ae9c0f44bf50b9>

Ulrich