1 |
On Thu, 20 Dec 2007 12:48:31 +0000 |
2 |
Steve Long <slong@××××××××××××××××××.uk> wrote: |
3 |
> Point is that your filename format restricts it in exactly the same |
4 |
> manner. So let's just stick with the use cases which /that/ supports, |
5 |
> which can more easily be supported with the original design and the |
6 |
> simple restriction people keep asking for. |
7 |
|
8 |
Er, the use case is having trivial-as-possible ebuilds for things that |
9 |
really are purely eclass managed. |
10 |
|
11 |
> >> No: without knowing the EAPI when generating said data. If that |
12 |
> >> needs to be known relatively soon in order to generate the rest, |
13 |
> >> extract it early. You still only need to load the file from disk |
14 |
> >> once, and you don't need to source to get that data, given one |
15 |
> >> simple restriction (only declaring it once.) |
16 |
> > |
17 |
> > You can't get the EAPI from the ebuild without knowing what EAPI the |
18 |
> > ebuild uses. That's one of the points you're missing. |
19 |
> > |
20 |
> Wow that doesn't half sound like nonsense. |
21 |
|
22 |
Unfortunately, it's not nonsense. It's entirely true. If you don't |
23 |
understand that then you can't contribute anything useful to the |
24 |
discussion, so kindly stay out of it. |
25 |
|
26 |
> An EAPI="blah" at top-level in the file is exactly the same as the |
27 |
> suffix in terms of what can be represented |
28 |
|
29 |
But not in what can be changed. |
30 |
|
31 |
> According to the original discussion this was always supposed to be a |
32 |
> variable set in the ebuild source: |
33 |
|
34 |
And things moved on. Right back when this first came up several people |
35 |
pointed out why a variable isn't an optimal solution. |
36 |
|
37 |
> At that time others made the case for restricting its format in |
38 |
> exactly the same way you have been resisting for the ebuild source, |
39 |
> but see as fine for tacking onto the end of the filename: |
40 |
> "I would also suggest requiring that EAPI can be retrieved by a |
41 |
> simple line by line parsing without using bash. (This allows for |
42 |
> changing the parsing system)"[2] |
43 |
|
44 |
Except that that proposal doesn't work, as we've already established. |
45 |
|
46 |
> The idea of a different suffix was discussed back then as well: |
47 |
> "portage *should not* ignore those ebuilds. If the user |
48 |
> wants to merge something that is a later ebuild api then they have, |
49 |
> at least portage chucks an exception that the UI can wrap into |
50 |
> 'upgrade portage'. |
51 |
|
52 |
There are times when the ebuilds have to be ignored. |
53 |
|
54 |
> With what you're proposing, we instead get bugs about portage missing |
55 |
> packages."[3] |
56 |
|
57 |
Only when absolutely necessary -- and it's only absolutely necessary |
58 |
when introducing changes such as version suffix extensions that would |
59 |
result in packages not being usable anyway. |
60 |
|
61 |
> (That was written when there were no other PMs besides |
62 |
> portage3/pkgcore) |
63 |
|
64 |
Learn your history. |
65 |
|
66 |
> > It's an ebuild issue, not a package manager issue. |
67 |
> > |
68 |
> You keep saying that; sure EAPI is visible to ebuild and maintainer |
69 |
> (doh) but the reason you have stated for this change in file naming |
70 |
> (which is a lot more far-reaching than a simple restriction on the |
71 |
> format of a variable) is so that the *PM* doesn't have to source the |
72 |
> ebuild to get the EAPI. |
73 |
|
74 |
It's so that the ebuild's EAPI can be extracted. The way things are |
75 |
currently, there is no way to get an ebuild's EAPI without already |
76 |
knowing its EAPI. |
77 |
|
78 |
> > You're confusing the two different types of metadata. Which again |
79 |
> > shows that you need to start understanding the metadata process |
80 |
> > before trying to discuss design decisions relating to it... |
81 |
> > |
82 |
> It doesn't make any practical difference[4]: the computational issue |
83 |
> is how to avoid a source statement via bash from another language. |
84 |
> |
85 |
> I note in passing that a metadata cache is available, with no runtime |
86 |
> requirement on the user's part, since it is taken from the rsync'ed |
87 |
> data. |
88 |
|
89 |
And *again* you demonstrate that you don't understand the metadata |
90 |
process. The metadata cache cannot be generated without already knowing |
91 |
the ebuild's EAPI, which is part of its metadata. |
92 |
|
93 |
> >> (optimising early here seems silly tbh, given that paludis now |
94 |
> >> requires ruby.) |
95 |
> > |
96 |
> > Eh? Now what're you on about? |
97 |
> > |
98 |
> http://bugs.gentoo.org/show_bug.cgi?id=198864 |
99 |
|
100 |
Thankyou for demonstrating to everyone that you don't know what a USE |
101 |
flag is. |
102 |
|
103 |
> >> >> > Ebuilds are not config files. |
104 |
> >> >> > |
105 |
> >> >> Indeed not, but they can be parsed as such for simple, core, |
106 |
> >> >> metadata. |
107 |
> >> > |
108 |
> >> > There is currently no information available from an ebuild that |
109 |
> >> > can be parsed by any tool other than bash. |
110 |
> >> > |
111 |
> >> OK, but restricting EAPI= across the board (in the way that others |
112 |
> >> have already asked for) and enforcing it via repoman would mean |
113 |
> >> EAPI could easily be extracted. |
114 |
> > |
115 |
> > Except that it's an arbitrary, pointless restriction. |
116 |
> > |
117 |
> Er arbitrary, no, since in practise it means exactly the same thing |
118 |
> as the filename suffix (one single string declaration.) Pointless not |
119 |
> at all, since it allows you to avoid calling bash and waiting for it |
120 |
> to source, without an ugly hack. It also keeps the existing work |
121 |
> practises that everyone is used to and doesn't mandate any changes to |
122 |
> support tools. |
123 |
|
124 |
...and imposes arbitrary, pointless restrictions upon the format, which |
125 |
is exactly what EAPI is supposed to prevent. |
126 |
|
127 |
> >> Hmm I think you should consider the example that this sub-thread is |
128 |
> >> about, and whether an apology would be in order. |
129 |
> > |
130 |
> > Huh? |
131 |
> > |
132 |
> Gee is it really that hard to look back at the example from your |
133 |
> colleague that started this sub-thread? Yet you expect everyone else |
134 |
> to keep track of every delightful comment from you.. *sigh* |
135 |
|
136 |
The problem is, it's rather hard to keep track of what you think you're |
137 |
going on about when your arguments are based upon a very limited |
138 |
understanding of what's being discussed. |
139 |
|
140 |
> >> Since only declaring it the once /seems/ ok with you, what on Earth |
141 |
> >> is so hard about extracting it? |
142 |
> > |
143 |
> > With the current situation, the EAPI has to be known for the EAPI |
144 |
> > to be calculated. Adding in a pre-pass layer enforcing new file |
145 |
> > format restrictions does not solve the problem we're trying to |
146 |
> > address. |
147 |
> > |
148 |
> There is no pre-pass layer enforcing restrictions (nice FUD though); |
149 |
|
150 |
No, there's a pre-pass layer which by its existence enforces |
151 |
restrictions. |
152 |
|
153 |
> [4] But thanks for the explanation, that really cleared things up. |
154 |
> I'll assume you're talking about metadata generation during depgraph |
155 |
> resol'n then, until you scold me for misunderstanding again. And I |
156 |
> note that you have been disparaging of discussion of bash |
157 |
> optimisations in eclass/ebuild code, yet are falling over yourself to |
158 |
> give everyone else a load of work to speed up what I thought was |
159 |
> already the fastest PM known to humanity. |
160 |
|
161 |
Uh... It's not a performance issue. And again you show just how badly |
162 |
you fail to get what's being discussed. |
163 |
|
164 |
-- |
165 |
Ciaran McCreesh |