1 |
On Tue, 16 May 2006 10:33:56 -0700 Brian Harring <ferringb@×××××.com> |
2 |
wrote: |
3 |
| > What eapi=0 standard? We emulate Portage internals where it's found |
4 |
| > to be necessary, and don't otherwise. |
5 |
| |
6 |
| eapi=0 is what 2.1/2.05x supports. |
7 |
|
8 |
That's not really true. Relying upon "anything that Portage handles", |
9 |
including relying upon Portage bugs and internals, leads to broken |
10 |
ebuilds when said things change. |
11 |
|
12 |
| Features are fine, but for gentoo backwards compatibility *is* a |
13 |
| concern, as such dropping the bits that you dislike (but existing |
14 |
| ebuilds rely on) is a no go. |
15 |
|
16 |
You're acting like Paludis is dropping something huge here. Not |
17 |
emulating a few weird PORTAGE_ variables that nothing uses is not |
18 |
breaking eapi. If ebuilds genuinely rely upon something, we emulate as |
19 |
necessary. |
20 |
|
21 |
| > | Mind you that's from a quick read through |
22 |
| > | of your ebuild env reimplementation, stated the issues already |
23 |
| > | and they still remain- incomplete support for the standard is one |
24 |
| > | thing, changing it is another (y'all are doing the latter). |
25 |
| > |
26 |
| > What standard? Are you trying to say that Paludis should emulate |
27 |
| > Portage's bugs, because the standard is "exactly what Portage does"? |
28 |
| |
29 |
| See above. Paludis (my view) is a rewrite of portage, rather then a |
30 |
| reimplementation- as you've stated, dropping the stuff that you deem |
31 |
| misfeatures. |
32 |
|
33 |
A 'rewrite' implies that we're starting from "what Portage does", and |
34 |
making something that does the same thing in the same way. That's not |
35 |
how it's being done. We're looking at it a) from what ebuilds do, and |
36 |
b) from what the program is expected to do, and then filling in the |
37 |
middle. The only part that's really at all close to Portage is the bash |
38 |
stuff for ebuilds, and that's pretty much necessary because of the |
39 |
ebuild <-> package manager interface thing. |
40 |
|
41 |
*shrug* Your perception on this one's probably skewed if (as it seems) |
42 |
you've been focusing on the trivial and easily replaceable bash part, |
43 |
rather than the interesting things which are done in C++. |
44 |
|
45 |
| This is fine, but portage *is* what gentoo is based uses now, and |
46 |
| what all ebuilds have been written to, as such you need to either |
47 |
| support the misfeatures or have a bullet proof transition plan to |
48 |
| deal with the things you decided to carve out. |
49 |
|
50 |
Which, funnily enough, is what we do. |
51 |
|
52 |
| This is directly relevant because you now want to modify the |
53 |
| gentoo-x86 repo to standards gentoo does not actually support. Call |
54 |
| it "dropping the misfeatures", but it's the reality of backwards |
55 |
| compatibility (something that has been kicking portage devs in the |
56 |
| nuts for years now). |
57 |
|
58 |
Again, not really true. Said Portage devs have pushed through far |
59 |
larger changes than anything we need -- look at the "use becoming useq" |
60 |
behaviour changes, for example. Paludis does not require or want any |
61 |
such large change, and we'd consider anything that required that to be |
62 |
broken. |
63 |
|
64 |
| Feature introduction is done via introducing support, then sitting on |
65 |
| it for ~6 months to ensure folks don't get bit by it- notable |
66 |
| exception was virtuals/* metapkg, although the buttload of bugs from |
67 |
| it is a demonstration of *why* this route must be taken. |
68 |
|
69 |
There is a difference between "changes that affect people not using the |
70 |
newer package manager" and "changes that are only relevant to people |
71 |
using the newer package manager". Anyone asking for features that will |
72 |
lead to Portage breaking will be beaten with a spork. |
73 |
|
74 |
| This is also why eapi came about- faster introduction of |
75 |
| compatibility breaking changes. |
76 |
|
77 |
Which, unfortunately, it doesn't really do, since ebuilds still have to |
78 |
be filename and source compatible. There were far better ways this |
79 |
could have been handled. |
80 |
|
81 |
| Meanwhile, the precedent for changes to the tree (pkg manager related |
82 |
| changes) is that of "don't break shit for users", introducing N |
83 |
| parent inherit profiles into the tree still qualifies as a concern- |
84 |
| as stated, you're after demoing capabilities, do it somewhere other |
85 |
| then production data. |
86 |
|
87 |
N parent inherit profiles don't break anything for users who don't use |
88 |
said profiles. Any user switching to an unsuitable profile, N parent or |
89 |
not, will end up with a h0rked system. The same occurs when new |
90 |
profiles requiring newer Portage versions are introduced, and that's |
91 |
been done several times. |
92 |
|
93 |
| Snarky response aside, I read the src (note the env screwups I've |
94 |
| pointed out, and the fact y'all don't support try eclass unified |
95 |
| overlays), and your documentation- the point was that paludis can |
96 |
| only be used for new installs, and you're locked to paludis as your |
97 |
| pkg manager at that point without a translation script. |
98 |
|
99 |
Had you read the source or the documentation, you'd know fine well that |
100 |
we support eclass unified overlays. I really think you should refrain |
101 |
from making those kinds of claims until you actually have the slightest |
102 |
clue what you're talking about. |
103 |
|
104 |
| Trying to make it clear that paludis isn't something you try out for |
105 |
| a bit, then revert back to portage- it's a full rebuild. That |
106 |
| seriously limits the usefulness of the requested profile. |
107 |
|
108 |
Sure. Which is why it's a profile scope thing, the same as, say, |
109 |
multilib. |
110 |
|
111 |
| Just because something is a viable alternative to portage doesn't |
112 |
| mean the tree should be mutated to the alternative |
113 |
|
114 |
Adding a subprofile is not mutating the tree. Get a sense of |
115 |
perspective here. We're not asking everyone to change how they invoke |
116 |
the 'use' function... |
117 |
|
118 |
| Yes, paludis is a viable pkg manager- it's not viable to work with |
119 |
| ebuilds written to portage (eapi=0) however |
120 |
|
121 |
Sure it is. |
122 |
|
123 |
| One thing I am curious about though, is how closely you've checked |
124 |
| things are running properly- ebuilds have preserved their state in |
125 |
| local vars saved in the env dump for well over 2 years, cutting that |
126 |
| out on a whim for 22k ebuilds is kind of risky. It'll show at |
127 |
| unmerge time and for binpkgs... |
128 |
|
129 |
Funnily enough, we know what we're doing. |
130 |
|
131 |
| > Uh, a user changing to any incorrect profile will screw up their |
132 |
| > system. Ever tried using an amd64 profile on x86? |
133 |
| |
134 |
| We can't do anything about that idiocy. |
135 |
| |
136 |
| That doesn't mean a profile should be added to the tree that portage |
137 |
| is incapable of resolving properly however- simple example would be |
138 |
| inheriting from two parents, one that's base arch agnostic defaults, |
139 |
| other is arch specific modifications. |
140 |
|
141 |
Huh? Profiles that some Portage versions can't use have been added |
142 |
plenty of times previously. |
143 |
|
144 |
| > | eapi incompatibility |
145 |
| > |
146 |
| > You mean "not emulating some of Portage's sillier bugs that very few |
147 |
| > things rely upon anyway", right? |
148 |
| |
149 |
| See above. Renaming of PORTAGE_* -> PALUDIS_* vars doesn't strike me |
150 |
| as "sillier bugs", strikes me as "we stamped it with our name, thus |
151 |
| introducing subtle bugs into minor packages like perl". |
152 |
|
153 |
We emulate some PORTAGE_ variables. We don't emulate the ones that |
154 |
aren't necessary. |
155 |
|
156 |
| And yes, that's actually a valid example- easy to spot via just a |
157 |
| simple grepping of the tree (I suggest you do so). |
158 |
|
159 |
Heh. You lose. It isn't. |
160 |
|
161 |
| Point is, the tree (you're own words) is not a playground, nor is it |
162 |
| a demoscene- don't introduce the potential for screwup in the tree |
163 |
| without a damn good reason. |
164 |
|
165 |
That argument is like claiming that adding an amd64 profile to the tree |
166 |
is a potential screwup because x86 users might use it. |
167 |
|
168 |
| Bluntly, you break compatibility with vdb/tree, paludis has no real |
169 |
| future with gentoo beyond forking- requiring 100,000 users to |
170 |
| reinstall because you don't want to do backwards compatibility is |
171 |
| daft. |
172 |
|
173 |
A reinstall isn't needed at all. |
174 |
|
175 |
| The original discussion was about adding a paludis profile (not |
176 |
| "portage sucks"), getting back to it, paludis is incompatible with |
177 |
| portage at the actual ebuild level- considering that, why should the |
178 |
| tree be modified to add a profile that's just going to introduce |
179 |
| further breakage? |
180 |
|
181 |
Paludis is no more incompatible with ebuilds than any new Portage |
182 |
release is. |
183 |
|
184 |
-- |
185 |
Ciaran McCreesh |
186 |
Mail : ciaran dot mccreesh at blueyonder.co.uk |
187 |
|
188 |
|
189 |
-- |
190 |
gentoo-dev@g.o mailing list |