| 1 |
On Mon, 18 Feb 2008 17:19:55 -0500 |
| 2 |
Doug Klima <cardoe@g.o> wrote: |
| 3 |
> > Well, that depends upon whether you want it to be part of the C/P-V |
| 4 |
> > metadata... If you do, it's a cache format change (and you can't |
| 5 |
> > easily do DEPRECATED_*). But then, deprecation is a property of the |
| 6 |
> > eclass, not an C/P-V. |
| 7 |
> |
| 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 |
Ciaran McCreesh |
Archives