| Summary: | eutils.eclass: unstable check_license() behaviour can break third party PMs | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Fabio Erculiani (RETIRED) <lxnay> |
| Component: | Eclasses | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | VERIFIED FIXED | ||
| Severity: | normal | CC: | caster, dev-portage |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
proposed fix to eutils.eclass
correct patch that would solve the issue with dying when ACCEPT_LICENSE is set |
||
Created attachment 201118 [details, diff]
proposed fix to eutils.eclass
Created attachment 201120 [details, diff]
correct patch that would solve the issue with dying when ACCEPT_LICENSE is set
sorry, this is the correct patch
This almost becomes moot with ACCEPT_LICENSE handling in portage, but could check_license tell the user that he can use ACCEPT_LICENSE to avoid further interactive agreements? Third party portage library users have to be able to control interactivity and interactive requests in a stable way. Since portage.doebuild() calls eclass code, this MUST also expose a controllable interactivity. I'm CCing Portage developers to make them aware of the issue. Having unreliable interactivity control breaks every application that is using Portage API. (In reply to comment #4) > Third party portage library users have to be able to control interactivity and > interactive requests in a stable way. Since portage.doebuild() calls eclass > code, this MUST also expose a controllable interactivity. > I'm CCing Portage developers to make them aware of the issue. Having unreliable > interactivity control breaks every application that is using Portage API. With >=portage-2.1.7.x, it's guaranteed to never be interactive because: 1) emerge masks the package if user's ACCEPT_LICENSE is not suitable 2) if ACCEPT_LICENSE is suitable, check_license is not interactive (In reply to comment #2) > Created an attachment (id=201120) [details] > correct patch that would solve the issue with dying when ACCEPT_LICENSE is set I've committed this patch in cvs. (In reply to comment #4) > Third party portage library users have to be able to control interactivity and > interactive requests in a stable way. Since portage.doebuild() calls eclass > code, this MUST also expose a controllable interactivity. Setting ACCEPT_LICENSE="*" with >=portage-2.1.7.x should guarantee non-interactivity. The config.setcpv() method will populate ACCEPT_LICENSE for the ebuild environment with the appropriate licenses so that check_license is non-interactive. Thanks Zac, I think we can close this (time to move on ;)). |
This is more or less food for thoughts, not sure if you would consider this a bug but still, my brainless POV led me thinking it is. For a test ebuild, look at net-wireless/broadcom-sta (which contains check_license in pkg_setup with no arguments (that won't work if LICENSE="|| ( foo foo2 )")) In eutils.eclass check_license() is defined and follows this rationale: 1. check if argument 1 is provided and set ${lic} 2. if ${lic} is not set, default it to ${PORTDIR}/licenses/${LICENSE} 3. check if ${lic} is a valid file path, if not, die! * 4. check for ACCEPT_LICENSE and in case of match, skip license request I think that correct behaviour would be: 1. check if argument 1 is provided and set ${lic} 2. if ${lic} is not set, default it to ${PORTDIR}/licenses/${LICENSE} 3. check if `basename ${lic}` is in ACCEPT_LICENSE and skip license request if so 4. otherwise, check if ${lic} is a valid file path, if not, die! Other than this *tech* (perhaps) issue, there is another, deeper concern. Third party Portage-based package managers (like Entropy does) can provide their own license management stuff and need to override Portage one, changing accept_license() could cause those PMs to fail to disable eclasses license management by just setting ACCEPT_LICENSE. So, it would be nice to formalize an "official" way to disable this feature in a way that can be safe for third party Portage API users (via portage.doebuild()). Reproducible: Always