1 |
On Tue, 16 May 2006 12:55:11 -0700 Brian Harring <ferringb@×××××.com> |
2 |
wrote: |
3 |
| > That's not really true. Relying upon "anything that Portage |
4 |
| > handles", including relying upon Portage bugs and internals, leads |
5 |
| > to broken ebuilds when said things change. |
6 |
| |
7 |
| ...which is why the ebuild env for portage is extremely carefully |
8 |
| maintained- mistakes may occur, but willy nilly changes don't. |
9 |
| Regardless, at least for gentoo it still however *is* the standard |
10 |
| for ebuilds, breaking the 'standard' out of portage is fine, changing |
11 |
| intrinsic parts of the standard isn't. |
12 |
|
13 |
What standard? |
14 |
|
15 |
| > You're acting like Paludis is dropping something huge here. Not |
16 |
| > emulating a few weird PORTAGE_ variables that nothing uses is not |
17 |
| > breaking eapi. If ebuilds genuinely rely upon something, we emulate |
18 |
| > as necessary. |
19 |
| |
20 |
| Then I'll state it again; you're changing the core environment |
21 |
| handling via intentionally dropping all local vars defined per phase |
22 |
| run. |
23 |
|
24 |
Yes, we're intentionally not emulating a Portage misfeature and will |
25 |
carry on not doing so until we come across a genuine case where this |
26 |
causes breakage that isn't better fixed by other means. We haven't said |
27 |
we definitely won't hack Paludis to make local variables not actually |
28 |
local the way Portage does. Equally, we're not going to make that |
29 |
change unless there's a damned good reason to do so. |
30 |
|
31 |
| Add binpkgs, and try it- you'll get some fun behaviour there. |
32 |
|
33 |
As we're not emulating Portage's binary package format, it's not an |
34 |
issue at all. |
35 |
|
36 |
| > *shrug* Your perception on this one's probably skewed if (as it |
37 |
| > seems) you've been focusing on the trivial and easily replaceable |
38 |
| > bash part, rather than the interesting things which are done in C++. |
39 |
| |
40 |
| The bash part is all that matters, hence why I'm focusing on it- as |
41 |
| you stated above, the data (ebuilds) handling is what matters. |
42 |
|
43 |
A lot of the ebuild handling (especially environment) is done in C++. |
44 |
You're missing all kinds of things by only looking at the bash code. |
45 |
|
46 |
| > There is a difference between "changes that affect people not using |
47 |
| > the newer package manager" and "changes that are only relevant to |
48 |
| > people using the newer package manager". Anyone asking for features |
49 |
| > that will lead to Portage breaking will be beaten with a spork. |
50 |
| |
51 |
| N profile inheritance breaks portage. |
52 |
| You were saying? |
53 |
|
54 |
N profile inheritance does not break Portage unless someone mis-sets |
55 |
their profile. Plenty of changes have been made that would trigger the |
56 |
same class of breakage were the user to mis-set their profile. We are |
57 |
not asking for N inheritance in profiles that will be used by Portage. |
58 |
|
59 |
| Feel free to suggest them- since it's initial discussion, your |
60 |
| comments on it haven't really progressed beyond "y'all did it badly", |
61 |
| without naming a solution that works. |
62 |
|
63 |
I gave you two that worked. One, the .ebuild.n thing, which avoids the |
64 |
filename incompatibility issue and the source issue. Two, the "eapi as a |
65 |
function" thing, which avoids the source issue. |
66 |
|
67 |
| > Had you read the source or the documentation, you'd know fine well |
68 |
| > that we support eclass unified overlays. I really think you should |
69 |
| > refrain from making those kinds of claims until you actually have |
70 |
| > the slightest clue what you're talking about. |
71 |
| |
72 |
| Offhand, you're ignoring the point about lack of translation script |
73 |
| for vdb, and that paludis requires a new install. |
74 |
|
75 |
Doesn't actually require it. It's just a good idea to do so, and we're |
76 |
not going to support people who don't *at this stage*. |
77 |
|
78 |
| Re: eclass, had to dig in the src for that one, doc's don't cover |
79 |
| it. |
80 |
|
81 |
Sure they do. It's included as part of the bootstrap howto doc. |
82 |
|
83 |
| Your repositories support specifying an arbitrary eclass- they do |
84 |
| not support the standard unification on the fly of eclass that most |
85 |
| portage users use- *technically* it can be done via copying eclasses |
86 |
| from each repo into an eclass directory (better yet symlinks), but |
87 |
| that's not unifying- that's working around the implementation. |
88 |
|
89 |
Which is a good thing. Rather than emulating one of Portage's sillier |
90 |
misfeatures, which only came about because of the whole "single |
91 |
repository" concept being hard-coded, we did it properly. |
92 |
|
93 |
| > Huh? Profiles that some Portage versions can't use have been added |
94 |
| > plenty of times previously. |
95 |
| |
96 |
| Yep, and we still get bugs about .50- that doesn't mean it's right |
97 |
| (just because someone else did something stupid doesn't mean you |
98 |
| can). It's pretty simple, don't stick stuff into the tree that can |
99 |
| silently fail, stick stuff in that is detected instead of silent |
100 |
| failures. |
101 |
|
102 |
It won't be a silent failure. |
103 |
|
104 |
| > | Point is, the tree (you're own words) is not a playground, nor is |
105 |
| > | it a demoscene- don't introduce the potential for screwup in the |
106 |
| > | tree without a damn good reason. |
107 |
| > |
108 |
| > That argument is like claiming that adding an amd64 profile to the |
109 |
| > tree is a potential screwup because x86 users might use it. |
110 |
| |
111 |
| x86 users could at *least* render the profile out properly. All |
112 |
| gentoo users sans the few paludis experimenters cannot use N profile |
113 |
| inheritance, and portage will misbehave with it. Wrong profile is |
114 |
| pretty damn obvious (compilation failure)- partially loaded profile |
115 |
| is a bit different however, you only get part of the profile tree |
116 |
| loaded (likely enough to continue on), but not all of it's settings. |
117 |
|
118 |
No no, it can be made to explode as noisily as we like. |
119 |
|
120 |
| Bit retarded here, but seriously, work it out in the overlay (like |
121 |
| most herds do), then try to bring it to the tree. |
122 |
|
123 |
Oh, we already went through that stage. |
124 |
|
125 |
| > | Bluntly, you break compatibility with vdb/tree, paludis has no |
126 |
| > | real future with gentoo beyond forking- requiring 100,000 users |
127 |
| > | to reinstall because you don't want to do backwards compatibility |
128 |
| > | is daft. |
129 |
| > |
130 |
| > A reinstall isn't needed at all. |
131 |
| |
132 |
| Currently is, going by your docs (and last look through code)- url? |
133 |
|
134 |
Isn't going to be documented, because I don't want people doing that |
135 |
just now. |
136 |
|
137 |
| > Paludis is no more incompatible with ebuilds than any new Portage |
138 |
| > release is. |
139 |
| |
140 |
| Rhetoric. I've pointed out specific changes you've gone and done |
141 |
| that render it incompatible, and the response is "portage does it |
142 |
| worse"? Portage doesn't willy nilly convert/drop vars, nor screw with |
143 |
| the env handling. |
144 |
|
145 |
Not emulating Portage bugs isn't an incompatibility. |
146 |
|
147 |
| That and the thread is getting fairly wide in discusion, rather then |
148 |
| the profile specific "does alt pkg manager X cruft belong in the |
149 |
| tree?" |
150 |
|
151 |
Well yes, because rather than discussing the issues, you're trying to |
152 |
turn this into your personal crusade against Paludis. |
153 |
|
154 |
-- |
155 |
Ciaran McCreesh |
156 |
Mail : ciaran dot mccreesh at blueyonder.co.uk |
157 |
|
158 |
|
159 |
-- |
160 |
gentoo-dev@g.o mailing list |