On Thu, Sep 22, 2005 at 01:30:00PM -0400, Chris Gianelloni wrote: > On Thu, 2005-09-22 at 11:46 -0500, Brian Harring wrote: > > Actually, it does have to deal with glep23, and you already stated in > > one of you emails (an "interim solution *now* since I've not heard > > anything from GLEP23 for some time"). > > This is an interim solution only in that it flags a package as > commercial until there is some kind of group created to fill that role. > Personally, I don't think a group *should* be created for commercial > licenses, as they are *not* equal in any way and should be judged > individually, rather than as a group. In that case, this would be a > permanent solution.
Yet what you're proposing *is* a marker on packages as "this is commercial", in effect a license grouping that's not properly implemented. > > Further, where do you think you're going to migrate the check for this > > license to? > > We wouldn't check for *this* license. We would be checking for the > *real* license. > > So rather than using "check_license" in pkg_setup, we would be using > "check_license Q3AEULA". As for where it will eventually migrate (ala > GLEP23), I don't know, and honestly, it isn't my concern. It's actually your concern whether you realize it or not. Your idea of just ignoring "commercial" if it appears in license.split() means that ACCEPT_LICENSE implementation now gets screwed with, and has to start maintaining a whitelist of strings to exempt from checks. Why is this an issue? LICENSE field isn't a "one of the licenses listed", it's "all of the licenses listed following depset syntax rules". Same syntax as DEPEND. In other words, you can't stick a daft marker into the LICENSE field just the same as you can't stick daft atom's into DEPENDS; portage *must* resolve it. If the LICENSE depset doesn't match the users ACCEPT_LICENSE, then the package is masked. What you're proposing directly breaks glep23 (re-read the EBUILD License Variable section). (Heading it off), no, a || ( DOOM3 commercial ) won't work either, that's _either_ commercial license accepted, or doom3. > > FYI, accept_license checks have been sitting in svn/cvs for about a > > month, same as use deps. No, you can't use them now in a released > > portage, but that's not much of a reason to introduce a fake license > > I'm sitting. Further, a better approach instead of people adhocing > > yet another band aid in the tree would be to chip in- you want glep23? > > Yes, I want GLEP23, but as I have said, I think this *could* be a > permanent solution, if used properly. Nope, see above. It's the same old issue of "we want portage to do xyz", then something ugly/bad gets implemented that is a kludge getting in the way of a proper solution. That's harsh, but it's also the truth from being on the receiving end of portage bugs/watching the tree. It's easier to slap a (imo) crap solution into the tree then to do the proper route of trying to implement a proper solution. > > help bring the *proper*, agreed upon solution to a stable portage, not > > taking the easier route. > > OK. I'm going to ask a question of you. If you do an "emerge -S doom3" > on your system, how would you know that the DOOM3 license is a > commercial license? How would you know the difference between "doom3" > and "doom3-demo", which happen to have the *exact* same license? How > would you know that "doom3" requires a purchase? How would GLEP23 > resolve this? > > Now, if you can give me a solution other than the one that I have > provided, then I'll gladly accept it. As it stands, I only see one way > to provide this information to our users, and that is to add it > *somehow* into the ebuilds. This means either via LICENSE or some new > variable. The advantage to using LICENSE is that it works *now* on all > versions of portage. It also works *now* on packages.gentoo.org's > pages. Logic here is rather flawed. How do you know that the GPL is a 'opensource' license? How do you know that the sorcerer public license is anti-forking? You get off your ass and look in the licenses directory, that's how. What you're proposing doesn't in any way help with educating people on what the licenses are that they're accepting; sticking "commercial" into the license field is a bad hack, pure and simple. I'll kill this one off further down... > > The original proposed angle (glep23 implementation isn't here) is > > jumping the gun, and the angle of "it indicates it costs money" isn't > > proper either. > > > > You want to indicate that this *specific* pkg costs money > > (something not related to the license it's released under I might > > add)? Stick it in metadata.xml or DESCRIPTION. > > Description is the worst place for it, IMO. I'd have no problem > sticking it in metadata.xml, either, but tell me how users are to get > that information? As it stands now, the only data in metadata.xml that > is used for *anything* is the herd/maintainer information, and that > information isn't available from portage, but only from external > 3rd-party applications and jeeves. >=2.1 portage supports querying from metadata.xml. Stable portage doesn't do a lot of things (like reading metadata.xml), but there's no reason later versions can't add in the missing functionality/feature. > > So... my 2 cents? No (was obvious already, wasn't it? :) > > Great. Give me another way to let the user know that the package > requires a purchase or obtaining a license that we cannot provide them. Gave you another way, and I also clarifed why this isn't just a bad idea, you _cannot_ do this. You view description as the wrong place for this; well, I view it as the proper place. License in no way relates to if the binaries/source must be purchased or not. It's a description thing. "ID's DOOM3 game, non shareware version" fex. Further, you're stating that "commercial" shouldn't be used as any form of grouping, but that _is_ what you're attempting- > If you do an "emerge -S doom3" on your system, how would you know that > the DOOM3 license is a commercial license? You read the license, silly, rather then blindly accepting licenses. The difference between doom3 and doom3-demo *should* be reflected in the DESCRIPTION also, since it's... the pkgs description data ;) The fields exist for what you're after; I don't know why you're after the abuse of the LICENSE field, but it won't fly without a heck of a lot more kicking/screaming from me, and a reversal/ammendment of glep23. Alternatives/better approaches I'd be open to, although I'll admit up front I think what you're attempting needs to be pkg specific, which implies DESCRIPTION in the ebuild (to me at least). ~harring
pgpnStEofRgWI.pgp
Description: PGP signature
