Licenses may be accepted per package by defining an atom in /etc/portage/package.license, i.e., ``` # This allows 'license' for category/package category/package license ``` However, this cannot be used within a profile. The only way to accept a license within a profile is in make.defaults, but that then affects _every_ package. Just as profiles allow package.use, etc. to tweak individual package settings from within the profile, package.license should be supported to do the same. Reproducible: Always Steps to Reproduce: echo "category/package license" >> /etc/portage/make.profile/package.license emerge category/package Actual Results: Package is masked by a license not accepted in /etc/portage/make.conf (et al) Expected Results: Package in unmasked and emerges.
For consistency with package.accept_keywords, I'd like to call it package.accept_license.
(In reply to Zac Medico from comment #1) > For consistency with package.accept_keywords, I'd like to call it > package.accept_license. I think you're kind of in a pickle if you want consistency here. As per `portage(5)`, the file for defining overrides to `ACCEPT_LICENSE` and/or the profile is `/etc/portage/package.license`. I've always kind of thought that file should be `package.accept_license` to match the variable in `make.conf(5)` anyway, but that's a call for you to make.
Came here to file this bug. Regardless of the naming of the file, the functionality of accepting licenses per-package is the only one of the package.* files that appears to be required to be in /etc/portage instead of profiles. I use a profile in my own overlay to manage my portage configuration for multiple hosts. In my profile, I can configure all the USE flags, keywords, etc, but I can't accept licenses per-package because of this bug.
For portage, we could add a profile-formats extension for this. We recently did something similar for repository deps (bug 651208).
This is comparable to accepting keywords for a package, which cannot be done in a profile either? Renaming the file to package.accept_license would clarify that it's part of the user configuration (overriding/augmenting ACCEPT_LICENSE in make.conf).
(In reply to Ulrich Müller from comment #5) > This is comparable to accepting keywords for a package, which cannot be done > in a profile either? That is correct. While accepting keywords and licenses for specific packages could possibly be rejected as profile features, essentially anything that a user would want to put in profiles needs to be supported either via EAPI or something like profile-formats as discussed in bug 417013. > Renaming the file to package.accept_license would clarify that it's part of > the user configuration (overriding/augmenting ACCEPT_LICENSE in make.conf). Yes, although I find myself questioning the value of this "user configuration" distinction. In practice, users then to desire as much of the usual user configuration features as possible when they create profiles.
(In reply to Ulrich Müller from comment #5) > This is comparable to accepting keywords for a package, which cannot be done > in a profile either? I'm not sure I follow. I have a package.accept_keywords file in my overlay's profile that works just fine. The following all work for me in my overlay's profile: make.defaults package.accept_keywords package.mask package.use where package.license does not work.
(In reply to Zac Medico from comment #6) > (In reply to Ulrich Müller from comment #5) > > This is comparable to accepting keywords for a package, which cannot be done > > in a profile either? > > That is correct. While accepting keywords and licenses for specific packages > could possibly be rejected as profile features, essentially anything that a > user would want to put in profiles needs to be supported either via EAPI or > something like profile-formats as discussed in bug 417013. The spec doesn't mention package.keywords and package.accept_keywords either, and I am not sure that it should (see below). So yes, maybe we should have an additional document for such features. > > Renaming the file to package.accept_license would clarify that it's part of > > the user configuration (overriding/augmenting ACCEPT_LICENSE in make.conf). > > Yes, although I find myself questioning the value of this "user > configuration" distinction. In practice, users then to desire as much of the > usual user configuration features as possible when they create profiles. It is user configuration in the sense that you wouldn't put it in a profile in the gentoo repository, nor in any public overlay.
(In reply to Tom Samstag from comment #7) > > This is comparable to accepting keywords for a package, which cannot be done > > in a profile either? > > I'm not sure I follow. I have a package.accept_keywords file in my overlay's > profile that works just fine. Right. I stand corrected.
