| 1 |
Ciaran McCreesh kirjoitti: |
| 2 |
> On Mon, 18 Feb 2008 17:19:55 -0500 |
| 3 |
> Doug Klima <cardoe@g.o> wrote: |
| 4 |
>>> Well, that depends upon whether you want it to be part of the C/P-V |
| 5 |
>>> metadata... If you do, it's a cache format change (and you can't |
| 6 |
>>> easily do DEPRECATED_*). But then, deprecation is a property of the |
| 7 |
>>> eclass, not an C/P-V. |
| 8 |
>> Deprecation is a property of the eclass. Not of an ebuild. The point |
| 9 |
>> is to allow utilities and users/developers to clearly see that an |
| 10 |
>> eclass is deprecated and what they should be using in place of it. |
| 11 |
> |
| 12 |
> Right. eclasses don't currently have metadata (and there's no easy way |
| 13 |
> for them to have it, since eclasses can't be sourced standalone). If |
| 14 |
> you make deprecation a metadata variable, there will be no way for a |
| 15 |
> package manager to determine whether an eclass is deprecated unless it |
| 16 |
> has an ebuild that uses that eclass. Is this a satisfactory restriction? |
| 17 |
> |
| 18 |
|
| 19 |
A metadata.xml like file for eclasses could fit the bill. It could have |
| 20 |
both the maintainer info and the deprecation information among other |
| 21 |
things. |
| 22 |
|
| 23 |
Regards, |
| 24 |
Petteri |
Archives