1 |
On Wed, 03 Mar 2010 13:09:49 +0200 |
2 |
Petteri Räty <betelgeuse@g.o> wrote: |
3 |
|
4 |
> On 3.3.2010 11.23, Nirbheek Chauhan wrote: |
5 |
> > 2010/3/3 Tomáš Chvátal <scarabeus@g.o>: |
6 |
> >>>> Removing eclass functions like this is not allowed by current policy. If |
7 |
> >>>> you want to do it, you should discuss about changing policy. |
8 |
> >>> |
9 |
> >>> ?! |
10 |
> >>> |
11 |
> >>> since when? |
12 |
> >>> |
13 |
> >> Since ever. |
14 |
> >> If you change eclass abi you need to rename it. |
15 |
> >> |
16 |
> > |
17 |
> > I think you can *add* functions and variables to eclasses, you can |
18 |
> > change *how* a function works internally, you can *fix* problems with |
19 |
> > functions (which would technically result in a change in API). I don't |
20 |
> > think it has ever been as strict as, say, the kernel ABI interface. |
21 |
> > |
22 |
> |
23 |
> Yes, eclasses go along the same lines as shared libraries, which is |
24 |
> probably what Tomáš meant any way. |
25 |
|
26 |
Is this actually documented anywhere? Or is this another of our |
27 |
"this-is-policy-because-everyone-knows-it's-policy" policies? I know there |
28 |
was a technical issue with removing pkg_*_rm functions way-back-when, but if |
29 |
there's no technical reason why functions can't be deprecated, and we're just |
30 |
clinging to policy in the name of policy, then I can't say I see the point. |
31 |
|
32 |
And if this is such a bad idea, then can we get it in writing? |
33 |
|
34 |
|
35 |
-- |
36 |
fonts, by design, by neglect |
37 |
gcc-porting, for a fact or just for effect |
38 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |