This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Providing/Packaging a Postinstalled SUSV4 Doc only Package a la Debian


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]