On Sat, 10 Sep 2011 17:34:51 +0200 Michael Schreckenbauer <grim...@gmx.de> wrote:
> On Saturday, 10. September 2011 17:19:36 Alex Schuster wrote: > > Michael Schreckenbauer writes: > > > On Saturday, 10. September 2011 16:50:30 Alex Schuster wrote: > > > > What you need to do is to tell portage you accept the license by > > > > putting the >=dev-java/... line > > > > into /etc/portage/package.license. Or > > > > you could add the --autounmask-write switch to your emerge > > > > command, and then use etc-update/dispatch-conf/cfg-update or > > > > whatever you use to update the config files. > > > > > > Ah. This /etc/portage/package.license thing is new to me. > > > I use ACCEPT_LICENSE in make.conf. > > > You know, what's the difference (if any)? > > > > No, I don't there is any. Just like with ACCEPT_KEYWORDS. It's just > > cleaner to have this in package.license I think. > > > > The man pages for portage and make.conf have some more information > > on this. > > Thanks. The difference is, that package.license is per package. > So one could set ACCEPT_LICENSE in make.conf and override this > setting for some packages in package.license. > Now I wonder, what the use-cases would be? > Why would one accept a specific license for package A, but not for > package B? I imagine it's more a theoretical and consistency thing rather than something that has a real need right now. Maybe someone filed a feature request and Zac figured it was easy to implement as the framework is already there for the existing package.* stuff. I could be useful though, I can totally see someone needing to accept a restrictive license for one package, but not another. Companies do odd things with licenses, it's quite realistic for a company to require an agreement of some kind before one may install certain sources, but this agreement doesn't cover other packages that have the same license. I can't think of an example right now though. Maybe an Adobe EULA for flash would fit the bill - you accept it for v9 but not for v10 and the user might want to record that fact instead of just simply masking an ebuild. -- Alan McKinnnon alan.mckin...@gmail.com
