1 |
On Thursday 19 July 2012 02:57:09 Ulrich Mueller wrote: |
2 |
> >>>>> On Wed, 18 Jul 2012, Ciaran McCreesh wrote: |
3 |
> >> Many eclasses (eutils being the most prominent example) contain: |
4 |
> >> DESCRIPTION="Based on the ${ECLASS} eclass" |
5 |
> >> |
6 |
> >> Is this of any use? |
7 |
> > |
8 |
> > The reason that sort of thing is there is because in the olden days |
9 |
> > before we had specs or EAPIs or anything like that, eclasses were |
10 |
> > originally designed and implemented as "classes" in an OO type manner. |
11 |
> > The idea was that there would be a "base" eclass, and then you'd derive |
12 |
> > "kde", "gnome" etc eclasses from there, all in a nice hierarchy, and |
13 |
> > you'd be expected to "override" variables like DESCRIPTION as you go |
14 |
> > down the tree. |
15 |
> > |
16 |
> > As it turns out, eclasses ended up being used in a completely different |
17 |
> > way. But you still see bits of the original idea cropping up, such as |
18 |
> > in the words "class" and "inherit" and "base". |
19 |
> |
20 |
> Thanks, this explains why these DESCRIPTIONs are there. |
21 |
> |
22 |
> But history left aside, are they still useful today? If not, then they |
23 |
> should be removed. |
24 |
|
25 |
it depends. for some of the eclasses which are just eblits, it makes sense |
26 |
(e.g. toolchain/mariadb/etc...). for some plugin based ones, it also makes |
27 |
sense because the packages are fairly mechanical in nature (e.g. stardict/ |
28 |
linux-kernel/etc...). for core ones (like eutils), i liked it in the past |
29 |
because it provided a quick way to detect when someone had their inherit order |
30 |
wrong (although this isn't nearly as common a problem anymore). |
31 |
|
32 |
so some trimming could probably be done, and we should probably discourage new |
33 |
eclasses from just copying & pasting, but removing it from all eclasses |
34 |
doesn't make much sense. |
35 |
-mike |