1 |
On Sun, Sep 16, 2012 at 08:45:09AM +0200, Ulrich Mueller wrote: |
2 |
> >>>>> On Tue, 11 Sep 2012, Brian Harring wrote: |
3 |
> |
4 |
> > To varying degrees, existing PMs use names that aren't prefixed in |
5 |
> > some fashion indicating it's an internal- the end result being |
6 |
> > ebuilds/eclasses that rely on a PM internal (both bad for alternate |
7 |
> > PMs, and bad should that internal change). |
8 |
> |
9 |
> > Further, the lack of a standardized namespace for the PMs internals |
10 |
> > means QA tools must maintain their own lists. As such, allocate __* |
11 |
> > for the PM to use for it's internal functionality and variables. |
12 |
> |
13 |
> We already have a section "Reserved Commands and Variables", and I |
14 |
> think that the information should be added there. See one-line patch |
15 |
> below. |
16 |
|
17 |
I'd frankly rather it in both locations. Ebuild devs are more likely |
18 |
to read the sections I tagged w/ this info, imo. |
19 |
|
20 |
> |
21 |
> I also wonder about the rest of the list: "abort", "dyn", "ebuild", |
22 |
> "hook", "paludis", "portage", "prep". |
23 |
|
24 |
The annoying thing about that list is that 'prep' has a few scenarios |
25 |
where it has to be used to get things done. |
26 |
|
27 |
It would be useful if rather than PMS stating "that's naughty, and |
28 |
screw you, we don't need to provide a solution to replace it", we |
29 |
documented some form of a solution. That's an age old bitching/rant |
30 |
point from when the doc was first written. We *really* need to clean |
31 |
that shit out, it makes the spec worthless in spots. |
32 |
|
33 |
Either way, that list isn't particularly accurate; the real problem |
34 |
aren't those, the problem is random bits of functionality laced into |
35 |
the env that are easy to mistake for eclass functionality- paludis in |
36 |
particular doesn't protect itself all that much. |
37 |
|
38 |
This is pretty much why I went the nuclear route; everything in __* |
39 |
unless it's explicitly exempted to keep existing behaviour working (in |
40 |
which case, we need to document or find solutions for those cases |
41 |
rather than pretend they don't exist). |
42 |
|
43 |
> [prep] occurs in |
44 |
> src_prepare, so forbidding it in ebuilds doesn't look so reasonable. ;-) |
45 |
|
46 |
Nice. :) |
47 |
|
48 |
> Some of the others (like "dyn" and "hook") are used in eclasses. |
49 |
> Should repoman enforce that they're not used? |
50 |
|
51 |
No. dyn_ is trying to block invocation of dyn_${phase}, dyn_preinst |
52 |
for example; it's a bit of a worthless proscribement due to the fact |
53 |
an ebuild can't sanely invoke the dyn_* functionality of portage |
54 |
(multilib attempts notwith standing). |
55 |
|
56 |
Honestly, I strongly think we should just go the route I proposed with |
57 |
this patch. For pkgcore, it's completely compliant for it's |
58 |
internal functions, and for it's variables most are prefixed w/ |
59 |
PKGCORE_; moving them to __ I'll do sometime this week. |
60 |
|
61 |
For portage, I moved 95% of the functionality; |
62 |
offhand the only thing left was register_{die,success}_hook which I'll |
63 |
get shortly. For portage, the environment needs work- I'd strongly |
64 |
appreciate it if you took care of that Zac since it requires touching |
65 |
both python and bash, and 1) portage code is fairly dense, meaning |
66 |
it's likely I'd make a bug or two, 2) I didn't make that mess (the |
67 |
cleaning of it is part of where pkgcore originated from) :) |
68 |
|
69 |
If required, with a fair amount of bitching during it I will do |
70 |
portages env cleaning. |
71 |
|
72 |
As for paludis, ciaran or dleverton should be able to sort their end |
73 |
of it. |
74 |
|
75 |
~harring |