Cygwin package naming?

Luke Kendall
Thu Sep 1 08:16:00 GMT 2011

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:
> FAQ:         
> Documentation:
> Unsubscribe info:

Thanks for all that!



Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list