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

[Brian Harring <ferringb@gmail.com>]

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