[gentoo-dev] [RFC] Deprecating an eclass

[gentoo-dev] [RFC] Deprecating an eclass

[Doug Klima]

Howdy all,

We need to agree upon some syntax which we can mark an eclass as 
deprecated and potentially point to a replacement or multiple replacements.

Discuss.

--
Doug
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] Deprecating an eclass

[Doug Klima]

Doug Klima wrote:
> Howdy all,
>
> We need to agree upon some syntax which we can mark an eclass as 
> deprecated and potentially point to a replacement or multiple 
> replacements.
>
> Discuss.
>
Ok. I guess no one else has any feelings about this.

Potentially doing something like:

DEPRECIATED="$DEPRECATED $ECLASS"

at the top of each deprecated eclass. In the end $DEPRECATED would have 
a list of all the eclasses that are deprecated?

Maybe even:

DEPRECATED_MYECLASS="myreplacement"

would mean that myeclass.eclass is replaced by myreplacement.eclass ?
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] Deprecating an eclass

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

On Mon, 18 Feb 2008 15:43:56 -0500
Doug Klima <cardoe@gentoo.org> wrote:
> Ok. I guess no one else has any feelings about this.
> 
> Potentially doing something like:
> 
> DEPRECIATED="$DEPRECATED $ECLASS"

Deprecated != depreciated.

> at the top of each deprecated eclass. In the end $DEPRECATED would
> have a list of all the eclasses that are deprecated?
> 
> Maybe even:
> 
> DEPRECATED_MYECLASS="myreplacement"
> 
> would mean that myeclass.eclass is replaced by myreplacement.eclass ?

Well, that depends upon whether you want it to be part of the C/P-V
metadata... If you do, it's a cache format change (and you can't easily
do DEPRECATED_*). But then, deprecation is a property of the eclass,
not an C/P-V.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] Deprecating an eclass

[Doug Klima]

Ciaran McCreesh wrote:
> On Mon, 18 Feb 2008 15:43:56 -0500
> Doug Klima <cardoe@gentoo.org> wrote:
>   
>> Ok. I guess no one else has any feelings about this.
>>
>> Potentially doing something like:
>>
>> DEPRECIATED="$DEPRECATED $ECLASS"
>>     
>
> Deprecated != depreciated.
>   
You caught my typo. You clearly still got the meaning of the e-mail...
>   
>> at the top of each deprecated eclass. In the end $DEPRECATED would
>> have a list of all the eclasses that are deprecated?
>>
>> Maybe even:
>>
>> DEPRECATED_MYECLASS="myreplacement"
>>
>> would mean that myeclass.eclass is replaced by myreplacement.eclass ?
>>     
>
> Well, that depends upon whether you want it to be part of the C/P-V
> metadata... If you do, it's a cache format change (and you can't easily
> do DEPRECATED_*). But then, deprecation is a property of the eclass,
> not an C/P-V.
>
>   
Deprecation is a property of the eclass. Not of an ebuild. The point is 
to allow utilities and users/developers to clearly see that an eclass is 
deprecated and what they should be using in place of it.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] Deprecating an eclass

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 916 bytes --]

On Mon, 18 Feb 2008 17:19:55 -0500
Doug Klima <cardoe@gentoo.org> wrote:
> > Well, that depends upon whether you want it to be part of the C/P-V
> > metadata... If you do, it's a cache format change (and you can't
> > easily do DEPRECATED_*). But then, deprecation is a property of the
> > eclass, not an C/P-V.
>
> Deprecation is a property of the eclass. Not of an ebuild. The point
> is to allow utilities and users/developers to clearly see that an
> eclass is deprecated and what they should be using in place of it.

Right. eclasses don't currently have metadata (and there's no easy way
for them to have it, since eclasses can't be sourced standalone). If
you make deprecation a metadata variable, there will be no way for a
package manager to determine whether an eclass is deprecated unless it
has an ebuild that uses that eclass. Is this a satisfactory restriction?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] Deprecating an eclass

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

Ciaran McCreesh kirjoitti:
> On Mon, 18 Feb 2008 17:19:55 -0500
> Doug Klima <cardoe@gentoo.org> wrote:
>>> Well, that depends upon whether you want it to be part of the C/P-V
>>> metadata... If you do, it's a cache format change (and you can't
>>> easily do DEPRECATED_*). But then, deprecation is a property of the
>>> eclass, not an C/P-V.
>> Deprecation is a property of the eclass. Not of an ebuild. The point
>> is to allow utilities and users/developers to clearly see that an
>> eclass is deprecated and what they should be using in place of it.
> 
> Right. eclasses don't currently have metadata (and there's no easy way
> for them to have it, since eclasses can't be sourced standalone). If
> you make deprecation a metadata variable, there will be no way for a
> package manager to determine whether an eclass is deprecated unless it
> has an ebuild that uses that eclass. Is this a satisfactory restriction?
> 

A metadata.xml like file for eclasses could fit the bill. It could have 
both the maintainer info and the deprecation information among other 
things.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] [RFC] Deprecating an eclass

[Torsten Rehn]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

On Monday 18 February 2008, Doug Klima wrote:
> Potentially doing something like:
> DEPRECIATED="$DEPRECATED $ECLASS"
> at the top of each deprecated eclass.

Adding deprecation info directly into the eclass file feels wrong to me. 
(Eclasses are free software after all and can be reused - ok, nobody will 
ever do that, but we're talking theory here - so we shouldn't put Gentoo 
policy in there.)

What about /usr/portage/profiles/deprecated_eclasses looking like

old_eclass_1,old_eclass_2:new_eclass_1,new_eclass_2

indicating that the old_eclasses have been deprecated by the new_eclasses. 
Having multiple eclasses deprecated by multiple eclasses may not be that 
common, but this kind of syntax allows for some grouping of related eclasses 
being replaced together.
-- 
Torsten Rehn <scel@xdap.org>
Gentoo AMD64 Arch Tester
http://scel.info

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]