1 |
Ciaran McCreesh wrote: |
2 |
>> >> Are you really telling me you are going to write _one_ ebuild |
3 |
>> >> with /that/ god-awful hackery in it? |
4 |
>> > |
5 |
>> > Are you really suggesting that no-one ever will? |
6 |
>> > |
7 |
>> They won't if the spec and the docs say it's restricted to a single |
8 |
>> instance, which can be checked trivially by repoman. The example |
9 |
>> given was contrived and not at all representative imo; for instance |
10 |
>> one could as easily do the same kind of thing with DESCRIPTION, but |
11 |
>> it would be of little use and just add confusion to no purpose. |
12 |
> |
13 |
> Except people *do* have generated DESCRIPTION etc, and with good |
14 |
> reason. A simple example is the vim-spell-* packages. |
15 |
> |
16 |
OK. Do you think a generated EAPI is a good idea? I'm curious as to how that |
17 |
would be reflected in the filename (as well as your reasons ofc.) |
18 |
|
19 |
>> > The pre/post source issue exists regardless of how EAPI is set -- |
20 |
>> > it's just that with filename EAPIs, you aren't restricted to post |
21 |
>> > source changes. |
22 |
>> |
23 |
>> And what benefit does that provide, besides making it easier for your |
24 |
>> package manager? |
25 |
> |
26 |
> It's not a question of ease. It's a question of being possible. You |
27 |
> need to understand the metadata generation process to understand why |
28 |
> the package manger has to assume a particular EAPI when generating the |
29 |
> metadata. Without the EAPI in the suffix, the assumed EAPI has to be |
30 |
> some weird combination of all existing and all possible future EAPIs -- |
31 |
> which isn't logically sound. |
32 |
> |
33 |
No: without knowing the EAPI when generating said data. If that needs to be |
34 |
known relatively soon in order to generate the rest, extract it early. You |
35 |
still only need to load the file from disk once, and you don't need to |
36 |
source to get that data, given one simple restriction (only declaring it |
37 |
once.) |
38 |
|
39 |
>> (I note this is a technical consideration of the implementation, |
40 |
>> given as a reason to change a clean API-- with consequences for |
41 |
>> workflow.) |
42 |
> |
43 |
> No no. It's already an ebuild-visible issue, and there's no way it |
44 |
> can't be that doesn't involve imposing restrictions upon every single |
45 |
> possible future EAPI. |
46 |
> |
47 |
The *reason* for the change is about the implementation, and it is not |
48 |
necessary. I accept it would make metadata generation quicker, but the |
49 |
end-user can already use -metadata-transfer atm and never need to run that |
50 |
process. It would save many more cycles if more users did imo (optimising |
51 |
early here seems silly tbh, given that paludis now requires ruby.) |
52 |
|
53 |
Given that, as a user I see no benefit to my machines that would justify the |
54 |
maintenance headache which I know as a coder this will result in. Quite |
55 |
apart from all the changes to supporting tools and workflow, it's pushing |
56 |
an implementation-specific datum into a namespace where it's neither needed |
57 |
nor useful, apart from to the implementation. Someone working on an ebuild |
58 |
will be looking at its text, and an end-user doesn't care. |
59 |
|
60 |
Revision numbers are of note to all parties, by contrast. |
61 |
|
62 |
>> > Ebuilds are not config files. |
63 |
>> > |
64 |
>> Indeed not, but they can be parsed as such for simple, core, metadata. |
65 |
> |
66 |
> There is currently no information available from an ebuild that can be |
67 |
> parsed by any tool other than bash. |
68 |
> |
69 |
OK, but restricting EAPI= across the board (in the way that others have |
70 |
already asked for) and enforcing it via repoman would mean EAPI could |
71 |
easily be extracted. |
72 |
|
73 |
>> > Really. It's a heck of a lot cleaner in the filename suffix. |
74 |
>> > |
75 |
>> Nah, it's an awful hack and you know it. It has nothing to do with |
76 |
>> package naming and is unnecessary exposure of internal data. -rN is |
77 |
>> ok, and there are rules on when and when not to bump rev; this is |
78 |
>> not. It's much cleaner specified as part of the ebuild in the same |
79 |
>> way as DESCRIPTION, so long as it is only specified once. |
80 |
>> |
81 |
>> Or do you see some real benefit to specifying EAPI more than once as |
82 |
>> in the example? If so, please share it. |
83 |
> |
84 |
> And again, you show that you don't understand what's going on. EAPI is |
85 |
> only specified once except where developers screw up. The GLEP merely |
86 |
> moves the EAPI to being set *before* the metadata is generated, which |
87 |
> removes all the restrictions that having EAPI as part of the ebuild's |
88 |
> content imposes. |
89 |
> |
90 |
Hmm I think you should consider the example that this sub-thread is about, |
91 |
and whether an apology would be in order. |
92 |
|
93 |
Since only declaring it the once /seems/ ok with you, what on Earth is so |
94 |
hard about extracting it? I'm sure ruby has sufficient text processing |
95 |
capability if the C++ is a bit much for you; I remember there was that |
96 |
long-term bug in paludis not being able to deal with whitespace in config |
97 |
files, so clearly something's up with your text-processing. Hope that's |
98 |
finally fixed now. |
99 |
|
100 |
|
101 |
-- |
102 |
gentoo-dev@g.o mailing list |