From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65344 invoked by alias); 24 May 2017 17:34:41 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 65080 invoked by uid 89); 24 May 2017 17:34:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=announce, Euro, daily, euro X-HELO: smtp-out-so.shaw.ca Received: from smtp-out-so.shaw.ca (HELO smtp-out-so.shaw.ca) (64.59.136.137) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 May 2017 17:34:39 +0000 Received: from [192.168.1.100] ([174.0.238.184]) by shaw.ca with SMTP id DaBEd4Qolyd2DDaBFdsbIk; Wed, 24 May 2017 11:34:41 -0600 X-Authority-Analysis: v=2.2 cv=F5wnTupN c=1 sm=1 tr=0 a=WqCeCkldcEjBO3QZneQsCg==:117 a=WqCeCkldcEjBO3QZneQsCg==:17 a=IkcTkHD0fZMA:10 a=aAOhKTdBq8euE5buiooA:9 a=TogLEAb6xR96hpX9:21 a=_qzYUfB7MZQJw2UK:21 a=QEXdDO2ut3YA:10 Reply-To: Brian.Inglis@SystematicSw.ab.ca Subject: Re: units issues References: <7f2814c4-518a-c097-de05-f4c694dbf362@SystematicSw.ab.ca> <8c55fe7c-5e1c-4bec-dab5-b04e86c59ec4@cygwin.com> <2e0bdfd4-9b99-1ae8-bd82-2b986529e0a4@dronecode.org.uk> <977d9380-31dc-78de-a260-16689664129d@SystematicSw.ab.ca> <5d9a21b5-2c14-c1e8-2c33-6038aef22ace@SystematicSw.ab.ca> <8737bvjxdp.fsf@Rainer.invalid> <2a783f3e-7c6a-20ab-2130-0d8b42c73111@SystematicSw.ab.ca> <6CF2FC1279D0844C9357664DC5A08BA23D259840@msgb10.nih.gov> To: cygwin-apps@cygwin.com From: Brian Inglis Message-ID: <82260ec3-7e59-093b-ddda-5c8d254afb06@SystematicSw.ab.ca> Date: Wed, 24 May 2017 17:34:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <6CF2FC1279D0844C9357664DC5A08BA23D259840@msgb10.nih.gov> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfLrpp//eMUzR3PzL+K5aqnohciMhhgLiOGUTEYSXmZGw4vAGmpnR7NmVh8OcuNI48rpZlJ5oKdYmmB870pek4wiGgsDOFctQoiw2BXUddbrXtOdpOfO7 zBVg3gVpdLsXSin6ngpcvFzCduzQuLZPB0ZoWQOXrGFnYabFkYMpgAwUbKKGa7gHj7J8q09g26cobQ== X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00148.txt.bz2 On 2017-05-24 10:26, Buchbinder, Barry (NIH/NIAID) [E] wrote: > Brian Inglis sent the following at Tuesday, May 23, 2017 10:37 PM >> On 2017-05-23 17:55, Doug Henderson wrote: >>> On 23 May 2017 at 15:49, Brian Inglis wrote: >>>> Updating the currencies only when setup is run seems to me to be >>>> insufficient if users want to use current currency conversions. >> It's a command line utility from GNU with currency conversion factors >> in a separate definition file included from the main file, updated by >> a Python script, which downloads an RSS XML file of current (Euro) >> rates from a free source with a permissive licence, and converts it to >> definitions acceptable to the utility, overwriting the existing file. >> >> The main issues are that, as currently implemented, currency rates are >> updated automatically by a postinstall script only when setup is run; >> setup may be running in an environment without external access, so the >> postinstall script will generate an error; users may not want or care >> about currency updates; and the postinstall script uses find to avoid >> updating if there is no currency file, or it has been updated recently. >> >> One option to deal with this is update the package to install a >> zero length currency definitions file, so currency conversions are >> not defined, but the program has no issues, and drop the permanent >> postinstall script to perform updates. Then announce and document that >> users who want updated currency conversion rates need to run the update >> script from the command line, a profile script, cron job, or Windows >> Scheduled Task, as is desirable if they use currency conversions. > I would prefer that by default updates happen automatically and those > who do not want automatic updates do something to stop them from > happening. For instance, someone who does not want updates makes the > definitions file read-only and have the script check for write > permission and exit or skip updating if the file cannot be written. A > zero length read-only file works if one is worried about someone using > stale conversion factors. An environmental variable whose existence > marks no-update might be another possibility. I agree with Achim that currency updates should not be done at postinstall, as the user could be doing an automated install with no external access, and we don't know that. With no guaranteed automatic execution facility, we don't even have a mechanism, how should updates should be done automatically and how can we provide this? Alternative suggestions for automated updates are welcome and why I am asking here. For other services, we leave it to users to figure out how to start them up and shut them down before setup is run. We could install an /etc/profile.d script which asks the user first time thru if they want daily currency updates during login over the network, and then either null or update currencies, and after do or do not update currencies. We could document how updates could be run: run the command from the shell, or add the necessary code to: some profile or profile.d script; command alias or function wrapper in some profile script; script which uses units currencies, cron job, or Windows Scheduled Task. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada