public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Luke Kendall <luke.kendall@cisra.canon.com.au>
To: <cygwin@cygwin.com>
Cc: audit <audit-mail-disclaimer@cisra.canon.com.au>
Subject: Re: Cygwin package naming?
Date: Thu, 01 Sep 2011 08:16:00 -0000	[thread overview]
Message-ID: <4E5F3F55.4040907@cisra.canon.com.au> (raw)
In-Reply-To: <4E5F0B15.7040408@cwilson.fastmail.fm>

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

      reply	other threads:[~2011-09-01  8:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-01  1:43 Luke Kendall
2011-09-01  1:53 ` Larry Hall (Cygwin)
2011-09-01  2:04   ` Christopher Faylor
2011-09-01  8:01   ` Luke Kendall
2011-09-01  4:34 ` Charles Wilson
2011-09-01  8:16   ` Luke Kendall [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E5F3F55.4040907@cisra.canon.com.au \
    --to=luke.kendall@cisra.canon.com.au \
    --cc=audit-mail-disclaimer@cisra.canon.com.au \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).