* More on Cygwin package naming @ 2011-09-05 3:15 Luke Kendall 2011-09-05 3:47 ` Larry Hall (Cygwin) 2011-09-05 15:39 ` Buchbinder, Barry (NIH/NIAID) [E] 0 siblings, 2 replies; 4+ messages in thread From: Luke Kendall @ 2011-09-05 3:15 UTC (permalink / raw) To: cygwin; +Cc: audit In my previous mail I may have used the wrong term ("package"): the term "package" seems to refer to each .tar.bz2 file (for the source and install files of each version). So perhaps I should instead be talking about "@-names" - the name that appears after an "@" in setup.ini. Anyway, this is all related to me trying to determine the licenses for each Cygwin "@-name". What I've found so far is that: - Most cygwin @-names are simply the upstream "vendor"s project name. - But it's not rare for the name not to match at all. This seems to happen when a parent Freshmeat project is split into several cygwin "@-named" pieces: in that situation, I can't find any automatable way to tie the child names back to the parent. E.g. libncurses9 is a cygwin item from within the ncurses freshmeat project; or libintl, libintl{2,3,8} in cygwin, which are all part of the gettext project on Freshmeat. Currently I'm resorting to human inspection. I'd love to know if there's some way to determine this kind of parent-child relationship. Is there some setup.hint or upset or genini file or info lurking around (where?) that I could scrape such information out of? Charles Wilson suggested it's safer to find licenses by looking in the source, but a minor problem is that to do that I must either download all the source "just in case" (doubling the download), or else I have to further complicate things to download on demand if I discover the install package doesn't contain any licenses. (So far I have only downloaded Cygwin by using setup.exe: perhaps I can do a wget of extra -src packages outside setup.exe, as needed. I've been developing all this license discovery automation under Linux, though it should work from an installed Cygwin too, I think.) Another minor worry is that a closer reading of <http://cygwin.com/setup.html>'s description of package naming, is talking more about .tar.bz2 version naming. I couldn't find anything that directly spoke about how the name after the "@" in setup.ini is chosen. It would be /nice/ if someone could confirm that the upstream project name is used for the @-names, or at least that cygwin does not use any existing Freshmeat project name and apply it to different software. BTW, Charles Wilson thought: > 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 But FYI, when I looked at Freshmeat, a comment from 2007 said gettext changed to GPL3, while noting that the libintl libraries remain at LGPLv2. 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: More on Cygwin package naming 2011-09-05 3:15 More on Cygwin package naming Luke Kendall @ 2011-09-05 3:47 ` Larry Hall (Cygwin) 2011-09-05 15:39 ` Buchbinder, Barry (NIH/NIAID) [E] 1 sibling, 0 replies; 4+ messages in thread From: Larry Hall (Cygwin) @ 2011-09-05 3:47 UTC (permalink / raw) To: cygwin On 9/4/2011 11:15 PM, Luke Kendall wrote: > It would be /nice/ if someone could confirm that the upstream project name > is used for the @-names, or at least that cygwin does not use any existing > Freshmeat project name and apply it to different software. FWIW, I think it's fair to say that there is a convention of using the upstream project name for the @-names. But as with all conventions, there are variations used when called for. I think it's fair to say that the last part of your statement is true but I also couldn't guarantee that it will always be. -- Larry _____________________________________________________________________ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: More on Cygwin package naming 2011-09-05 3:15 More on Cygwin package naming Luke Kendall 2011-09-05 3:47 ` Larry Hall (Cygwin) @ 2011-09-05 15:39 ` Buchbinder, Barry (NIH/NIAID) [E] 2011-09-06 0:59 ` Luke Kendall 1 sibling, 1 reply; 4+ messages in thread From: Buchbinder, Barry (NIH/NIAID) [E] @ 2011-09-05 15:39 UTC (permalink / raw) To: 'Luke Kendall', cygwin Luke Kendall wrote on Sunday, September 04, 2011, at 11:16 PM >In my previous mail I may have used the wrong term ("package"): the term >"package" seems to refer to each .tar.bz2 file (for the source and >install files of each version). So perhaps I should instead be talking >about "@-names" - the name that appears after an "@" in setup.ini. > >Anyway, this is all related to me trying to determine the licenses for >each Cygwin "@-name". What I've found so far is that: > >- Most cygwin @-names are simply the upstream "vendor"s project name. >- But it's not rare for the name not to match at all. This seems to >happen when a parent Freshmeat project is split into several cygwin >"@-named" pieces: in that situation, I can't find any automatable way to >tie the child names back to the parent. E.g. libncurses9 is a cygwin >item from within the ncurses freshmeat project; or libintl, >libintl{2,3,8} in cygwin, which are all part of the gettext project on >Freshmeat. Currently I'm resorting to human inspection. > >I'd love to know if there's some way to determine this kind of >parent-child relationship. Is there some setup.hint or upset or genini >file or info lurking around (where?) that I could scrape such >information out of? The directory structure of the download release directory might help. It is in the "install" line. Using your gettext/libintl example: install: release/gettext/libintl8/libintl8-0.18.1.1-1.tar.bz2 24375 bf501b540c768d63358426686c615530 Here's a start: cat setup.ini | \ sed -e '/^install: /!d'\ -e '/\/_obsolete\//d' \ -e 's,^install: release/,,' \ -e 's,/[^/]*$,,' \ -e 's,^GNOME/,,' \ -e 's,^KDE/,,' \ -e 's,^X\.Org/,,' \ -e 's,^X11/,,' | \ tr / ' ' | \ sort -u - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: More on Cygwin package naming 2011-09-05 15:39 ` Buchbinder, Barry (NIH/NIAID) [E] @ 2011-09-06 0:59 ` Luke Kendall 0 siblings, 0 replies; 4+ messages in thread From: Luke Kendall @ 2011-09-06 0:59 UTC (permalink / raw) To: cygwin; +Cc: audit Buchbinder, Barry (NIH/NIAID) [E] wrote: > Luke Kendall wrote on Sunday, September 04, 2011, at 11:16 PM > >> In my previous mail I may have used the wrong term ("package"): the term >> "package" seems to refer to each .tar.bz2 file (for the source and >> install files of each version). So perhaps I should instead be talking >> about "@-names" - the name that appears after an "@" in setup.ini. >> >> Anyway, this is all related to me trying to determine the licenses for >> each Cygwin "@-name". What I've found so far is that: >> >> - Most cygwin @-names are simply the upstream "vendor"s project name. >> - But it's not rare for the name not to match at all. This seems to >> happen when a parent Freshmeat project is split into several cygwin >> "@-named" pieces: in that situation, I can't find any automatable way to >> tie the child names back to the parent. E.g. libncurses9 is a cygwin >> item from within the ncurses freshmeat project; or libintl, >> libintl{2,3,8} in cygwin, which are all part of the gettext project on >> Freshmeat. Currently I'm resorting to human inspection. >> >> I'd love to know if there's some way to determine this kind of >> parent-child relationship. Is there some setup.hint or upset or genini >> file or info lurking around (where?) that I could scrape such >> information out of? >> > > The directory structure of the download release directory might help. > It is in the "install" line. Using your gettext/libintl example: > install: release/gettext/libintl8/libintl8-0.18.1.1-1.tar.bz2 24375 bf501b540c768d63358426686c615530 > > Here's a start: > > cat setup.ini | \ > sed -e '/^install: /!d'\ > -e '/\/_obsolete\//d' \ > -e 's,^install: release/,,' \ > -e 's,/[^/]*$,,' \ > -e 's,^GNOME/,,' \ > -e 's,^KDE/,,' \ > -e 's,^X\.Org/,,' \ > -e 's,^X11/,,' | \ > tr / ' ' | \ > sort -u > > Ah, I see - thank you. I hadn't imagined it could be that simple! Using it to assess what see package groups besides GNOME etc. need to be included in the regexps, it looks like just db, libggi, and mingw - does that seem right? : [luke@calixa] .../cygwin-rc; cat setup.ini | sed -e '/^install: /!d' -e '/\/_obsolete\//d' -e 's,^install: release/,,' -e 's,/[^/]*$,,' -e 's,^GNOME/,,' -e 's,^KDE/,,' -e 's,^X\.Org/,,' -e 's,^X11/,,' | tr / ' ' | sort -u | grep ' .* ' db db2 libdb2 db db2 libdb2-devel db db3.1 libdb3.1 db db3.1 libdb3.1-devel db db4.1 libdb4.1 db db4.1 libdb4.1-devel db db4.2 libdb4.2 db db4.2 libdb4.2-devel db db4.3 libdb4.3 db db4.3 libdb4.3-devel libggi libggi2 libggi2-devel libggi libggi2 libggi2-display-aa libggi libggi2 libggi2-display-file libggi libggi2 libggi2-display-terminfo libggi libggi2 libggi2-display-x libggi libggi2 libggi2-samples libggi libggimisc2 libggimisc2-devel libggi libggimisc2 libggimisc2-samples libggi libggiwmh0 libggiwmh0-devel libggi libggiwmh0 libggiwmh0-display-x libggi libggiwmh0 libggiwmh0-samples libggi libgii1 libgii1-devel libggi libgii1 libgii1-input-x mingw mingw-bzip2 mingw-libbz2_1 And you've also improved my sed knowledge - I'd never noticed the /regexp/! construct before! > - Barry > Disclaimer: Statements made herein are not made on behalf of NIAID. > > Thanks! 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-09-06 0:59 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-09-05 3:15 More on Cygwin package naming Luke Kendall 2011-09-05 3:47 ` Larry Hall (Cygwin) 2011-09-05 15:39 ` Buchbinder, Barry (NIH/NIAID) [E] 2011-09-06 0:59 ` Luke Kendall
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).