[gentoo-dev] RFC: ACCEPT_LICENSE and deprecation of check_license

[gentoo-dev] RFC: ACCEPT_LICENSE and deprecation of check_license

[Zac Medico]

Hi,

Since portage-2.1.7.x is stable now, with ACCEPT_LICENSE support, we
can think about deprecating check_license [1]. This will allow us to
avoid using PROPERTIES=interactive in cases when it is due to
check_license alone, since anything with a license in the @EULA
license group is automatically masked by the default
ACCEPT_LICENSE="* -@EULA" portage configuration [2].

[1] http://bugs.gentoo.org/show_bug.cgi?id=299095
[2] http://bugs.gentoo.org/show_bug.cgi?id=302645
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: ACCEPT_LICENSE and deprecation of check_license

[Petteri Räty]

On 20.2.2010 14.28, Zac Medico wrote:
> Hi,
> 
> Since portage-2.1.7.x is stable now, with ACCEPT_LICENSE support, we
> can think about deprecating check_license [1]. This will allow us to
> avoid using PROPERTIES=interactive in cases when it is due to
> check_license alone, since anything with a license in the @EULA
> license group is automatically masked by the default
> ACCEPT_LICENSE="* -@EULA" portage configuration [2].
> 
> [1] http://bugs.gentoo.org/show_bug.cgi?id=299095
> [2] http://bugs.gentoo.org/show_bug.cgi?id=302645

We could handle it like deprecating ebeep and epause. With EAPI=4 don't
define the function any more and the Portage version will be
sufficiently new to have ACCEPT_LICENSE.

Regards,
Petteri

Re: [gentoo-dev] RFC: ACCEPT_LICENSE and deprecation of check_license

[Zac Medico]

On 02/21/2010 09:08 AM, Petteri Räty wrote:
> On 20.2.2010 14.28, Zac Medico wrote:
>> Hi,
>>
>> Since portage-2.1.7.x is stable now, with ACCEPT_LICENSE support, we
>> can think about deprecating check_license [1]. This will allow us to
>> avoid using PROPERTIES=interactive in cases when it is due to
>> check_license alone, since anything with a license in the @EULA
>> license group is automatically masked by the default
>> ACCEPT_LICENSE="* -@EULA" portage configuration [2].
>>
>> [1] http://bugs.gentoo.org/show_bug.cgi?id=299095
>> [2] http://bugs.gentoo.org/show_bug.cgi?id=302645
> 
> We could handle it like deprecating ebeep and epause. With EAPI=4 don't
> define the function any more and the Portage version will be
> sufficiently new to have ACCEPT_LICENSE.

That's a good idea. However, we may want to deprecate check_license
it starting with EAPI=3 since the corresponding portage versions
already support ACCEPT_LICENSE.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: ACCEPT_LICENSE and deprecation of check_license

[Petteri Räty]

On 21.2.2010 14.17, Zac Medico wrote:
> On 02/21/2010 09:08 AM, Petteri Räty wrote:
>> On 20.2.2010 14.28, Zac Medico wrote:
>>> Hi,
>>>
>>> Since portage-2.1.7.x is stable now, with ACCEPT_LICENSE support, we
>>> can think about deprecating check_license [1]. This will allow us to
>>> avoid using PROPERTIES=interactive in cases when it is due to
>>> check_license alone, since anything with a license in the @EULA
>>> license group is automatically masked by the default
>>> ACCEPT_LICENSE="* -@EULA" portage configuration [2].
>>>
>>> [1] http://bugs.gentoo.org/show_bug.cgi?id=299095
>>> [2] http://bugs.gentoo.org/show_bug.cgi?id=302645
>>
>> We could handle it like deprecating ebeep and epause. With EAPI=4 don't
>> define the function any more and the Portage version will be
>> sufficiently new to have ACCEPT_LICENSE.
> 
> That's a good idea. However, we may want to deprecate check_license
> it starting with EAPI=3 since the corresponding portage versions
> already support ACCEPT_LICENSE.

Likely there wouldn't be any breakage with it doing it in EAPI 3 but it
would be against the eclass contract of not changing expected behavior.
Would be a win-win situation if we would get EAPI 4 :)

Regards,
Petteri

Re: [gentoo-dev] RFC: ACCEPT_LICENSE and deprecation of check_license

[Zac Medico]

On 02/21/2010 02:36 PM, Petteri Räty wrote:
> On 21.2.2010 14.17, Zac Medico wrote:
>> On 02/21/2010 09:08 AM, Petteri Räty wrote:
>>> On 20.2.2010 14.28, Zac Medico wrote:
>>>> Hi,
>>>>
>>>> Since portage-2.1.7.x is stable now, with ACCEPT_LICENSE support, we
>>>> can think about deprecating check_license [1]. This will allow us to
>>>> avoid using PROPERTIES=interactive in cases when it is due to
>>>> check_license alone, since anything with a license in the @EULA
>>>> license group is automatically masked by the default
>>>> ACCEPT_LICENSE="* -@EULA" portage configuration [2].
>>>>
>>>> [1] http://bugs.gentoo.org/show_bug.cgi?id=299095
>>>> [2] http://bugs.gentoo.org/show_bug.cgi?id=302645
>>>
>>> We could handle it like deprecating ebeep and epause. With EAPI=4 don't
>>> define the function any more and the Portage version will be
>>> sufficiently new to have ACCEPT_LICENSE.
>>
>> That's a good idea. However, we may want to deprecate check_license
>> it starting with EAPI=3 since the corresponding portage versions
>> already support ACCEPT_LICENSE.
> 
> Likely there wouldn't be any breakage with it doing it in EAPI 3 but it
> would be against the eclass contract of not changing expected behavior.

Given that check_license already returns silently if the user has
accepted the appropriate license(s) via ACCEPT_LICENSE, it's not
necessary to change the eclass contract in order to safely remove
PROPERTIES=interactive from EAPI=3 ebuilds.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: ACCEPT_LICENSE and deprecation of check_license

[Petteri Räty]

On 21.2.2010 14.49, Zac Medico wrote:
> On 02/21/2010 02:36 PM, Petteri Räty wrote:
>> On 21.2.2010 14.17, Zac Medico wrote:
>>> On 02/21/2010 09:08 AM, Petteri Räty wrote:
>>>> On 20.2.2010 14.28, Zac Medico wrote:
>>>>> Hi,
>>>>>
>>>>> Since portage-2.1.7.x is stable now, with ACCEPT_LICENSE support, we
>>>>> can think about deprecating check_license [1]. This will allow us to
>>>>> avoid using PROPERTIES=interactive in cases when it is due to
>>>>> check_license alone, since anything with a license in the @EULA
>>>>> license group is automatically masked by the default
>>>>> ACCEPT_LICENSE="* -@EULA" portage configuration [2].
>>>>>
>>>>> [1] http://bugs.gentoo.org/show_bug.cgi?id=299095
>>>>> [2] http://bugs.gentoo.org/show_bug.cgi?id=302645
>>>>
>>>> We could handle it like deprecating ebeep and epause. With EAPI=4 don't
>>>> define the function any more and the Portage version will be
>>>> sufficiently new to have ACCEPT_LICENSE.
>>>
>>> That's a good idea. However, we may want to deprecate check_license
>>> it starting with EAPI=3 since the corresponding portage versions
>>> already support ACCEPT_LICENSE.
>>
>> Likely there wouldn't be any breakage with it doing it in EAPI 3 but it
>> would be against the eclass contract of not changing expected behavior.
> 
> Given that check_license already returns silently if the user has
> accepted the appropriate license(s) via ACCEPT_LICENSE, it's not
> necessary to change the eclass contract in order to safely remove
> PROPERTIES=interactive from EAPI=3 ebuilds.

So we could keep check_license defined in EAPI 3 and remove interactive
from PROPERTIES and in EAPI 4 undefine it. We should also have a repoman
check so developers catch it.

Regards,
Petteri

Re: [gentoo-dev] RFC: ACCEPT_LICENSE and deprecation of check_license

[Zac Medico]

On 02/21/2010 03:00 PM, Petteri Räty wrote:
> On 21.2.2010 14.49, Zac Medico wrote:
>> On 02/21/2010 02:36 PM, Petteri Räty wrote:
>>> On 21.2.2010 14.17, Zac Medico wrote:
>>>> On 02/21/2010 09:08 AM, Petteri Räty wrote:
>>>>> On 20.2.2010 14.28, Zac Medico wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Since portage-2.1.7.x is stable now, with ACCEPT_LICENSE support, we
>>>>>> can think about deprecating check_license [1]. This will allow us to
>>>>>> avoid using PROPERTIES=interactive in cases when it is due to
>>>>>> check_license alone, since anything with a license in the @EULA
>>>>>> license group is automatically masked by the default
>>>>>> ACCEPT_LICENSE="* -@EULA" portage configuration [2].
>>>>>>
>>>>>> [1] http://bugs.gentoo.org/show_bug.cgi?id=299095
>>>>>> [2] http://bugs.gentoo.org/show_bug.cgi?id=302645
>>>>>
>>>>> We could handle it like deprecating ebeep and epause. With EAPI=4 don't
>>>>> define the function any more and the Portage version will be
>>>>> sufficiently new to have ACCEPT_LICENSE.
>>>>
>>>> That's a good idea. However, we may want to deprecate check_license
>>>> it starting with EAPI=3 since the corresponding portage versions
>>>> already support ACCEPT_LICENSE.
>>>
>>> Likely there wouldn't be any breakage with it doing it in EAPI 3 but it
>>> would be against the eclass contract of not changing expected behavior.
>>
>> Given that check_license already returns silently if the user has
>> accepted the appropriate license(s) via ACCEPT_LICENSE, it's not
>> necessary to change the eclass contract in order to safely remove
>> PROPERTIES=interactive from EAPI=3 ebuilds.
> 
> So we could keep check_license defined in EAPI 3 and remove interactive
> from PROPERTIES and in EAPI 4 undefine it. We should also have a repoman
> check so developers catch it.

That's a good plan. The repoman check may have to wait for EAPI 4
since it might be difficult to automatically to separate out cases
in EAPI 3 where PROPERTIES=interactive is due to check_license alone.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: ACCEPT_LICENSE and deprecation of check_license

[Petteri Räty]

On 21.2.2010 15.21, Zac Medico wrote:
>>>>
>>>> Likely there wouldn't be any breakage with it doing it in EAPI 3 but it
>>>> would be against the eclass contract of not changing expected behavior.
>>>
>>> Given that check_license already returns silently if the user has
>>> accepted the appropriate license(s) via ACCEPT_LICENSE, it's not
>>> necessary to change the eclass contract in order to safely remove
>>> PROPERTIES=interactive from EAPI=3 ebuilds.
>>
>> So we could keep check_license defined in EAPI 3 and remove interactive
>> from PROPERTIES and in EAPI 4 undefine it. We should also have a repoman
>> check so developers catch it.
> 
> That's a good plan. The repoman check may have to wait for EAPI 4
> since it might be difficult to automatically to separate out cases
> in EAPI 3 where PROPERTIES=interactive is due to check_license alone.

But it can still search for check_license and tell to migrate to
ACCEPT_LICENSE.

Regards,
Petteri

Re: [gentoo-dev] RFC: ACCEPT_LICENSE and deprecation of check_license

[Zac Medico]

On 02/21/2010 04:35 PM, Petteri Räty wrote:
> On 21.2.2010 15.21, Zac Medico wrote:
>>>>>
>>>>> Likely there wouldn't be any breakage with it doing it in EAPI 3 but it
>>>>> would be against the eclass contract of not changing expected behavior.
>>>>
>>>> Given that check_license already returns silently if the user has
>>>> accepted the appropriate license(s) via ACCEPT_LICENSE, it's not
>>>> necessary to change the eclass contract in order to safely remove
>>>> PROPERTIES=interactive from EAPI=3 ebuilds.
>>>
>>> So we could keep check_license defined in EAPI 3 and remove interactive
>>> from PROPERTIES and in EAPI 4 undefine it. We should also have a repoman
>>> check so developers catch it.
>>
>> That's a good plan. The repoman check may have to wait for EAPI 4
>> since it might be difficult to automatically to separate out cases
>> in EAPI 3 where PROPERTIES=interactive is due to check_license alone.
> 
> But it can still search for check_license and tell to migrate to
> ACCEPT_LICENSE.

Oh yes, good point.
-- 
Thanks,
Zac