X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.5 required=5.0	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Message-ID: <4E5F3F55.4040907@cisra.canon.com.au>
Date: Thu, 1 Sep 2011 18:16:21 +1000
From: Luke Kendall <luke DOT kendall AT cisra DOT canon DOT com DOT au>
User-Agent: Thunderbird 2.0.0.21 (X11/20090302)
MIME-Version: 1.0
To: <cygwin AT cygwin DOT com>
CC: audit <audit-mail-disclaimer AT cisra DOT canon DOT com DOT au>
Subject: Re: Cygwin package naming?
References: <4E5EE340 DOT 6010009 AT cisra DOT canon DOT com DOT au> <4E5F0B15 DOT 7040408 AT cwilson DOT fastmail DOT fm>
In-Reply-To: <4E5F0B15.7040408@cwilson.fastmail.fm>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Charles Wilson wrote:
> On 8/31/2011 9:43 PM, Luke Kendall wrote:
>   
>> I'm asking because I'm finding Cygwin packages that contain no license
>> information, at least in the compiled form (e.g. gawk, libiconv2).
>>     
>
> None of the "dll" packages contain license files; they are supposed to
> only contain the dll itself.  Usually the license files wind up in the
> "main" package, or a "-doc" package.
>   

Thanks, I'll bear that in mind.  Though gawk didn't have one.  But I'll 
have a bit more of a look around inside the tarballs, manually.

> However I think your BEST bet would be to do the following...get
> setup.ini from $favorite_mirror.  Every record beginning with
> 	'@ package'
> will have one or more 'source:' entries -- except for some _obsolete
> packages, but we don't care about those because they will just be empty
> tarballs, so no source necessary.  Multiple '@ package' will refer to
> the same 'source:'
>
>   

So, basically I think you're saying I should look inside the "source:" 
instead of the "install:" (which is where I've *been* looking).

Because I have to use a mix of algorithm and *heuristics* to find the 
license files, I'd prefer to try the heuristics on the "install:" tar 
file, just because the search space (no. of files) is much smaller.

Thanks for the suggestion, though, it sounds sensible - I'll have a 
manual look inside gawk's at least and see if that looks promising, and 
if so I'll modify the script to look inside the "source:" as a fallback.

> With some judicious coding (*), you should be able to flip that around,
> and create a database that represents the information the other way:
>
> <some source entry>-<VER-N>
>    @ package <1>-<VER-N>
>    @ package <2>-<VER-N>
>    @ package <3>-<VER-N>
> <some source entry>-<VER-M>  [same "package", different version]
>    @ package <1>-<VER-M>
>    @ package <2>-<VER-M>
>    @ package <3>-<VER-M>
> <another source entry>-<VER-P>
>    @ package <4>-<VER-P>
>    @ package <5>-<VER-P>
>
>   

I don't think I need to do that inversion - currently if I find the 
source licenses in package 1, and it's also used for package 2, then the 
script will automatically find the licenses for package 2.

> I doubt the license would often change between versions of the same
> package, but it HAS been known to happen.
>
>   

Sure.  At the moment, I'm only looking in the most recent version, too.  
I think looking in the source is more likely to find it if there's no 
license in the "install:" tarball.  I can't imagine someone deliberately 
stripping the license files out of a package.  That'd be just weird.

> Now, you can find the <package>s for which you can't identify the
> license, and either (a) find another package in the same "family" --
> e.g. derived from the same source -- for which you DO know the license.
>  WIN!
>
> If *all* of the "child" packages of a given source have an unknown
> license, well -- then you can get the -src package itself and troll
> around in it, or check freshmeat.  Usually the -src packages are named
> pretty simply:
>   <upstream name>-<upstream ver>-<cygwin release>-src.tar.*
>
> Watch out for this: some packages have different licenses for different
> pieces.  The "libiconv" group of packages specifies that the *libraries*
> are LGPL, but the *app* is GPL.  This means:
> 	libcharset1:	LGPL
> 	libiconv2:	LGPL
> 	libiconv:	GPL
>
> Also, gettext group is similar; some of the libs and apps are GPL, and
> some of the apps and libs are LGPL.  Fortunately, they are segregated in
> the cygwin packages:
> 	libasprintf0:	LGPL
> 	libintl8:	LGPL
> 	libgettextpo0:	GPL
> 	gettext:	LGPL
> 	gettext-devel	GPL
>
>   

Tell me about it.  "base-files" and "cygwin" are two good examples. :-)

> Fortunately, that sort of structure is rare.
>
> (*) Maybe borrow from genini, or upset?
>
> --
> Chuck
>
>
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>
>   

Thanks for all that!

Regards,

luke

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple