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
