Re: [gentoo-dev] Re: ACCEPT_LICENSE revisited

2006-12-01 Thread Brian Harring
On Fri, Dec 01, 2006 at 12:27:39PM +, Ciaran McCreesh wrote:
 On Fri, 01 Dec 2006 08:05:49 + Steve Long
 | Secondly, how difficult would it be for you to do what he asked? I
 | know it's not your responsibility, I just want to know whether you
 | can do it fairly easily.
 
 It's a couple of hours work, and it requires tree access...

anoncvs is available, just split a patch (tree wide changes could 
stand reviewing anyways).

~harring


pgpUUCjGzJczd.pgp
Description: PGP signature


Re: [gentoo-dev] Re: ACCEPT_LICENSE revisited

2006-12-01 Thread Ciaran McCreesh
On Fri, 1 Dec 2006 04:37:44 -0800 Brian Harring [EMAIL PROTECTED]
wrote:
| On Fri, Dec 01, 2006 at 12:27:39PM +, Ciaran McCreesh wrote:
|  On Fri, 01 Dec 2006 08:05:49 + Steve Long
|  | Secondly, how difficult would it be for you to do what he asked? I
|  | know it's not your responsibility, I just want to know whether you
|  | can do it fairly easily.
|  
|  It's a couple of hours work, and it requires tree access...
| 
| anoncvs is available, just split a patch (tree wide changes could 
| stand reviewing anyways).

Yeah, because a tree-wide patch against a changing tree is really
practical.

-- 
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13



signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: ACCEPT_LICENSE revisited

2006-12-01 Thread Brian Harring
On Fri, Dec 01, 2006 at 12:43:18PM +, Ciaran McCreesh wrote:
 On Fri, 1 Dec 2006 04:37:44 -0800 Brian Harring [EMAIL PROTECTED]
 wrote:
 | On Fri, Dec 01, 2006 at 12:27:39PM +, Ciaran McCreesh wrote:
 |  On Fri, 01 Dec 2006 08:05:49 + Steve Long
 |  | Secondly, how difficult would it be for you to do what he asked? I
 |  | know it's not your responsibility, I just want to know whether you
 |  | can do it fairly easily.
 |  
 |  It's a couple of hours work, and it requires tree access...
 | 
 | anoncvs is available, just split a patch (tree wide changes could 
 | stand reviewing anyways).
 
 Yeah, because a tree-wide patch against a changing tree is really
 practical.

Your changes will be fairly limited; pretty much tweaking LICENSE 
vars, mangling/adding to license/.  Yes, the tree changes, but it 
doesn't change fast enough for such a patch to be instantly worthless 
(nor worthless in a few weeks, albeit a bit dated).

Such a change *should* have review anyways, since LICENSE isn't 
something that should be arbitrarily screwed with.

Keep in mind that someone else is going to have to handle the patch 
anyways, so it's out of your hands at that point; let them worry about 
how to handle it, meanwhile you're after the change so throw the 
delta their way.

Donnie already stated he'd take a patch, so throw the patch his 
direction if you want things changed.

~harring


pgpLXmfgrUl8v.pgp
Description: PGP signature


Re: [gentoo-dev] Re: ACCEPT_LICENSE revisited

2006-12-01 Thread Ciaran McCreesh
On Fri, 1 Dec 2006 05:29:22 -0800 Brian Harring [EMAIL PROTECTED]
wrote:
| Donnie already stated he'd take a patch, so throw the patch his 
| direction if you want things changed.

If you don't want it to be broken, fix it yourself is hardly a viable
QA policy...

-- 
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13



signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: ACCEPT_LICENSE revisited

2006-11-22 Thread Marijn Schouten

Duncan wrote:

Marien Zwart [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on  Tue, 21
Nov 2006 19:36:35 +0100:


Since check_license was (I assume) originally added because it was
required for certain (mostly games) ebuilds: is the possibility to accept
the license by putting a wildcard or group in ACCEPT_LICENSE compatible
with those licenses? If it is not this would need some more thought: it
would be quite confusing if certain licenses did not follow the same
rules for groups and wildcards as other licenses, or if portage followed
different rules at resolve time than check_license in eutils does.


As I've read the GLEP (as proposed for update), you are missing something
here.  The package manager's treatment of ACCEPT_LICENSE will simply be
masking/unmasking of the appropriate ebuilds.  It won't change whether
interactive license agreement is required or not, simply whether such a
package is masked or not.  Thus, accepting an interactive license will be
a two-stage process -- (1) unmask it by setting ACCEPT_LICENCE
appropriately so the ebuild can even be considered for merging, (2) emerge
the package and hit the interactive merge section, actually accepting the
license there.

Setting ACCEPT_LICENSE therefore won't actually accept it.  It'll simply
tell the package manager whether it can consider certain packages or not. 
Once the package manager can do so, it can go ahead and actually display

the license for agreement if the package is actually merged.



Maybe it should be called ACCEPTABLE_LICENSES.

Marijn
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: ACCEPT_LICENSE revisited

2006-11-22 Thread Chris Gianelloni
On Wed, 2006-11-22 at 04:52 +, Duncan wrote:
 Marien Zwart [EMAIL PROTECTED] posted
 [EMAIL PROTECTED], excerpted below, on  Tue, 21
 Nov 2006 19:36:35 +0100:
 
  Since check_license was (I assume) originally added because it was
  required for certain (mostly games) ebuilds: is the possibility to accept
  the license by putting a wildcard or group in ACCEPT_LICENSE compatible
  with those licenses? If it is not this would need some more thought: it
  would be quite confusing if certain licenses did not follow the same
  rules for groups and wildcards as other licenses, or if portage followed
  different rules at resolve time than check_license in eutils does.
 
 As I've read the GLEP (as proposed for update), you are missing something
 here.  The package manager's treatment of ACCEPT_LICENSE will simply be
 masking/unmasking of the appropriate ebuilds.  It won't change whether
 interactive license agreement is required or not, simply whether such a
 package is masked or not.  Thus, accepting an interactive license will be
 a two-stage process -- (1) unmask it by setting ACCEPT_LICENCE
 appropriately so the ebuild can even be considered for merging, (2) emerge
 the package and hit the interactive merge section, actually accepting the
 license there.
 
 Setting ACCEPT_LICENSE therefore won't actually accept it.  It'll simply
 tell the package manager whether it can consider certain packages or not. 
 Once the package manager can do so, it can go ahead and actually display
 the license for agreement if the package is actually merged.

Nope.  The goal is for check_license to go away.  Please read bug
#152593 to see the discussion that's been going on with this.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Re: ACCEPT_LICENSE revisited

2006-11-22 Thread Chris Gianelloni
On Wed, 2006-11-22 at 10:57 +0100, Marijn Schouten wrote:
 Duncan wrote:
  Marien Zwart [EMAIL PROTECTED] posted
  [EMAIL PROTECTED], excerpted below, on  Tue, 21
  Nov 2006 19:36:35 +0100:
  
  Since check_license was (I assume) originally added because it was
  required for certain (mostly games) ebuilds: is the possibility to accept
  the license by putting a wildcard or group in ACCEPT_LICENSE compatible
  with those licenses? If it is not this would need some more thought: it
  would be quite confusing if certain licenses did not follow the same
  rules for groups and wildcards as other licenses, or if portage followed
  different rules at resolve time than check_license in eutils does.
  
  As I've read the GLEP (as proposed for update), you are missing something
  here.  The package manager's treatment of ACCEPT_LICENSE will simply be
  masking/unmasking of the appropriate ebuilds.  It won't change whether
  interactive license agreement is required or not, simply whether such a
  package is masked or not.  Thus, accepting an interactive license will be
  a two-stage process -- (1) unmask it by setting ACCEPT_LICENCE
  appropriately so the ebuild can even be considered for merging, (2) emerge
  the package and hit the interactive merge section, actually accepting the
  license there.
  
  Setting ACCEPT_LICENSE therefore won't actually accept it.  It'll simply
  tell the package manager whether it can consider certain packages or not. 
  Once the package manager can do so, it can go ahead and actually display
  the license for agreement if the package is actually merged.
  
 
 Maybe it should be called ACCEPTABLE_LICENSES.

How about ACCEPTABLE_KEYWORDS, too? *roll eyes*

Seriously folks, the variable is to indicate that you accept a license.
Hence, ACCEPT_LICENSE, just like how ACCEPT_KEYWORDS means you accept
that KEYWORD.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation


signature.asc
Description: This is a digitally signed message part