public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Zac Medico <zmedico@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] RFC: ACCEPT_LICENSE and deprecation of check_license
Date: Sun, 21 Feb 2010 15:21:41 -0800	[thread overview]
Message-ID: <4B81C005.8030507@gentoo.org> (raw)
In-Reply-To: <4B81BB1C.3070907@gentoo.org>

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



  reply	other threads:[~2010-02-22  0:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-20 22:28 [gentoo-dev] RFC: ACCEPT_LICENSE and deprecation of check_license Zac Medico
2010-02-21 17:08 ` Petteri Räty
2010-02-21 22:17   ` Zac Medico
2010-02-21 22:36     ` Petteri Räty
2010-02-21 22:49       ` Zac Medico
2010-02-21 23:00         ` Petteri Räty
2010-02-21 23:21           ` Zac Medico [this message]
2010-02-22  0:35             ` Petteri Räty
2010-02-22  0:43               ` Zac Medico

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B81C005.8030507@gentoo.org \
    --to=zmedico@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox