> On Fri, 10 Mar 2017 13:01:00 -0800 David Stacey wrote: > On 10/03/17 20:24, Achim Gratz wrote: >> On Fri, 10 Mar 2017 21:10:23 +0100 Corinna Vinschen writes: >>> On Fri, 10 Mar 2017 15:43:35 +0000 David Stacey wrote: >>>> On 2017-03-06 13:42, Brian Inglis wrote:
[sorry for not responding sooner to delayed replies - readded some context] >>>>> Debian provides a SUSV4 package which downloads the tar.bz2 and >>>>> installs the HTML tree from: >>>>> http://pubs.opengroup.org/onlinepubs/9699919799/download/ >>>>> in the postinstall script, as they believe that complies with >>>>> the terms permitting individual download stated and linked at: >>>>> http://pubs.opengroup.org/onlinepubs/terms.htm >>>>> http://www.opengroup.org/legal >>>>> Is there any interest in such a package in Cygwin, and is this >>>>> approach acceptable? >>>>> If this is not acceptable for packaging for any reason, I can >>>>> put the script up on github and mention it on the main list. >>> Yaakov asked our legal dept for advice and the result is this: >>> It's ok if the package downloads the tar file and unpacks it in a >>> post-install script, provided that the user gets an opportunity to >>> see http://pubs.opengroup.org/onlinepubs/terms.htm prior to the >>> installation. >>> For that to accomplish it's sufficient if the user gets pointed to >>> that document at install time. You can do this with an install >>> message. In cygport, add something like >>> MESSAGE="The content generated by this package is provided under >>> the terms as outlined by >>> http://pubs.opengroup.org/onlinepubs/terms.htm";; >>> That will do it. Thanks to you and Yaakov I will take the legal advice and add the suggested message. >>>> Otherwise, I am nervous about setting a precedent for a package >>>> that could give different contents each time it is installed >>>> (yes, Microsoft, I'm looking at you too). And there are plenty of >>>> corner cases where this wouldn't work: offline installs, web >>>> proxies, or if the account performing the Cygwin install (e.g. >>>> Administrator) was blocked from accessing the web (on security >>>> grounds). Will also add note and message about internet access. Those were also some of my concerns and why I asked before ITP. >> This is another interesting point of course. Does wget or curl >> allow to specify a (short) timeout before giving up and just not >> installing anything, perhaps? > Yes. 'wget' has --timeout=<seconds>. You can also set --dns-timeout, > --connect-timeout and --read-timeout for fine-grain control [1]. > However, the defaults are sensible and it gives up fairly quickly if > there's no network. Sensible for reliable automated downloads or quick failure, but for sites with any issues defaults 900s/15min timeouts and 20 retries can keep a process waiting for 5 hours - BTDT. If there are possible problems, as with mirrors, to reduce delays I cut retries to 0-3 times and timeout to 10s for my setup and uses. > 'curl' has --max-time and --connect-timeout [2]. Defaults to no retries, no redirects, network timeouts, so reasonable for most uses, and can be overridden for redirects and reliability. >> Regardless if that is possible (I think it is), I would not accept >> such a package into the standard distribution. For one, setup is >> not really equipped to handle such packages properly. Two, I really >> can't allow anything to download something from outside the >> internal network during the installation even where it might work. > I agree completely. I maintain what is effectively a private > corporate Cygwin Time Machine, so the company I work for can recreate > installations. Having this kind of repeatability is important to some > people. In one sense I can't get too excited - it's just a > documentation package after all - I'm just nervous that it sets a > precedent. What's next? Similar packages for non-free fonts? How > about a package that downloads the 'lame' source, builds it and > installs it, all from a post-install script? These might sound a bit > extreme, but you get my point. Appreciate your effort, feedback, and concerns. Will use the suggestions, modify the script, and put on github, probably as something like wget-posix-susv4-doc, to install in /usr/local/{,share/}doc/posix-susv4/. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
