1 |
On Wed, 19 Dec 2007 11:05:35 +0000 |
2 |
Steve Long <slong@××××××××××××××××××.uk> wrote: |
3 |
> Ciaran McCreesh wrote: |
4 |
> > On Wed, 19 Dec 2007 10:26:16 +0000 |
5 |
> > Steve Long <slong@××××××××××××××××××.uk> wrote: |
6 |
> >> Are you really telling me you are going to write _one_ ebuild |
7 |
> >> with /that/ god-awful hackery in it? |
8 |
> > |
9 |
> > Are you really suggesting that no-one ever will? |
10 |
> > |
11 |
> They won't if the spec and the docs say it's restricted to a single |
12 |
> instance, which can be checked trivially by repoman. The example |
13 |
> given was contrived and not at all representative imo; for instance |
14 |
> one could as easily do the same kind of thing with DESCRIPTION, but |
15 |
> it would be of little use and just add confusion to no purpose. |
16 |
|
17 |
Except people *do* have generated DESCRIPTION etc, and with good |
18 |
reason. A simple example is the vim-spell-* packages. |
19 |
|
20 |
> >> Sticking to a single EAPI="xx" format in the ebuild means we don't |
21 |
> >> have the *hack* of duplicating information in the filename (and the |
22 |
> >> whole {pre,post}src issue, QA checks for human error since this is |
23 |
> >> redundant info) simply to avoid parsing a config file. |
24 |
> > |
25 |
> > There is no duplication of information, nor redundancy. |
26 |
> > |
27 |
> So what were the QA checks you mentioned to confirm that the same |
28 |
> EAPI is set in both the filename and the ebuild, for-- if not |
29 |
> integrity of duplicated data? |
30 |
|
31 |
It's to catch developers screwing up an unnecessarily specifying EAPI |
32 |
manually. For example, someone might copy an EAPI 1 ebuild to |
33 |
a .ebuild-2. But the only time that will happen is when there's a |
34 |
screwup. |
35 |
|
36 |
> > The pre/post source issue exists regardless of how EAPI is set -- |
37 |
> > it's just that with filename EAPIs, you aren't restricted to post |
38 |
> > source changes. |
39 |
> |
40 |
> And what benefit does that provide, besides making it easier for your |
41 |
> package manager? |
42 |
|
43 |
It's not a question of ease. It's a question of being possible. You |
44 |
need to understand the metadata generation process to understand why |
45 |
the package manger has to assume a particular EAPI when generating the |
46 |
metadata. Without the EAPI in the suffix, the assumed EAPI has to be |
47 |
some weird combination of all existing and all possible future EAPIs -- |
48 |
which isn't logically sound. |
49 |
|
50 |
> (I note this is a technical consideration of the implementation, |
51 |
> given as a reason to change a clean API-- with consequences for |
52 |
> workflow.) |
53 |
|
54 |
No no. It's already an ebuild-visible issue, and there's no way it |
55 |
can't be that doesn't involve imposing restrictions upon every single |
56 |
possible future EAPI. |
57 |
|
58 |
> > Ebuilds are not config files. |
59 |
> > |
60 |
> Indeed not, but they can be parsed as such for simple, core, metadata. |
61 |
|
62 |
There is currently no information available from an ebuild that can be |
63 |
parsed by any tool other than bash. |
64 |
|
65 |
> > Really. It's a heck of a lot cleaner in the filename suffix. |
66 |
> > |
67 |
> Nah, it's an awful hack and you know it. It has nothing to do with |
68 |
> package naming and is unnecessary exposure of internal data. -rN is |
69 |
> ok, and there are rules on when and when not to bump rev; this is |
70 |
> not. It's much cleaner specified as part of the ebuild in the same |
71 |
> way as DESCRIPTION, so long as it is only specified once. |
72 |
> |
73 |
> Or do you see some real benefit to specifying EAPI more than once as |
74 |
> in the example? If so, please share it. |
75 |
|
76 |
And again, you show that you don't understand what's going on. EAPI is |
77 |
only specified once except where developers screw up. The GLEP merely |
78 |
moves the EAPI to being set *before* the metadata is generated, which |
79 |
removes all the restrictions that having EAPI as part of the ebuild's |
80 |
content imposes. |
81 |
|
82 |
-- |
83 |
Ciaran McCreesh |