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
prev parent 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).