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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Brian Inglis
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?

I have found it useful as it gives me local access to the latest POSIX
specs without needing to find the URL and go on the network.

If there is interest and the approach is acceptable, can cygport
produce a package consisting of only a doc directory and a
postinstall script?

I use cygport to download and build net packages of interest to me,
and maintain a local repo of them, so the regular packaging process is
familiar, including producing cygport, hint, and setup.ini files.

So if cygport won't work here, I can hand code whatever files are
required to provide a package.

As an example, I have attached the script I used as a text file so it
should appear inline and pass sourceware and any personal or corporate
mail filters, unless they scrub all kinds of attachments.

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.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

etc-postinstall-susv4-sh.txt (692 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Stacey
On 06/03/17 20:42, Brian Inglis wrote:

> 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?

Given that no-one else has replied:

Point (2) of the T&Cs linked above state that you are required to supply
a name and e-mail address for each publication requested. You're not
doing that (and neither should you without user consent), and so for me
it has to be an automatic 'No' for not complying with the T&Cs. IANAL.

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

My thoughts aren't all negative though - there's clearly benefit in what
you're trying to achieve.

Dave.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Corinna Vinschen-2
On Mar 10 15:43, David Stacey wrote:

> On 06/03/17 20:42, Brian Inglis wrote:
> > 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?
>
> Given that no-one else has replied:
Sorry for not replying earlier.  Yaakov asked our legel 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.

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

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?


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Achim Gratz
Corinna Vinschen writes:

>> 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).
>
> 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?

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.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Stacey
On 10/03/17 20:24, Achim Gratz wrote:

> Corinna Vinschen writes:
>>> 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).
>> 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.

'curl' has --max-time and --connect-timeout [2].

> 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 afterall - 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.

Dave.

[1] - https://linux.die.net/man/1/wget
[2] - https://linux.die.net/man/1/curl

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Brian Inglis
In reply to this post by Brian Inglis
> 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
Loading...