RE: [lmi] Creating end-user packages for msw

[Murphy, Kimberly]

Greg Chicares wrote:

> On 2010-03-22 18:26Z, Murphy, Kimberly wrote:
> > Greg Chicares wrote:
> [...]
> >> We could override $fardel_date_script if we want a 
> different outcome
> >> than the default provided, or change it if that's not an 
> appropriate
> >> default.
> > 
> > The first of a given month is appropriate for most end-user 
> > packages. On occasion, some end-users are provided the system 
> > a few days earlier. Waiting until the first of the month may 
> > not be a hardship in most situations, unless of course there's 
> > a feature someone wants to get their hands on. In this case, 
> > the 'fardel_date_script' could be overridden.
> 
> Okay, that's an important point. We need to be able to distribute
> off-cycle releases to fix critical defects or to add significant
> features. In that case, the begin-date would be the current date,
> and the end-date would be the same as usual.
> 
> Are there other cases that we should automate? 

While off-cycle releases are infrequent, they typically only 
require a change to the begin-date. Distributions that expire 
at end-dates other than the usual are rare. I can think of no
others.
 
> I believe authentication uses only the calendar date in the local
> timezone, without regard to the time of day. It should succeed
> from the first moment of the first day (because end users may be
> running illustrations one minute after midnight) through the
> last moment on the last day (so they can run illustrations one
> minute before midnight). I'm not sure whether the defaults in
> 'workhorse.make' do exactly that, but I'm pretty sure it's based
> on local time rather than UTC.

It is based on local time. The default dates in 'workhorse.make' 
aren't ideal for our end-user packages. For example, let's assume 
today, 2010-05-13, we're packaging the month-end release for use 
on June 1st. I run 'make fardel' and a 'lmi-20100513T1306Z' package 
is produced with an expiry of:

2455329 2455377

which coverts to:

JD 2455329.00000 is
CE 2010 May 12 12:00:00.0 UT  Wednesday

and

JD 2455377.00000 is
CE 2010 June 29 12:00:00.0 UT  Tuesday

Had this been the actual day the release was created, the dates 
would be incorrect. The begin-date is too early and the end-date 
is too soon. The actual expiry entered manually would be:

2455349 2455379

> The test in 'authenticity.cpp' looks like this:
> 
>     [candidate = current local date]
>     // Make sure candidate date is within valid range.
>     if(candidate < begin)
>       reject
>     if(end <= candidate)
>       reject
> 
> which leads me to guess that the specifying the first and last
> days of a month in 'expiry' would give the desired behavior.
> But the easiest way to find out for sure is to test it.

I agree it does sound as if it would give the behavior we 
want. Entering the first and last days of the month:

2010 May 1 00:00:00 UT
2010 May 31 00:00:00 UT

in the expiry like this,:

2455317.5 2455347.5

generates this error when launching Lmi:

---------------------------
Error
---------------------------
Untimely warning:
Error reading expiry file 'C:/opt/lmi/data/expiry'. 
Try reinstalling.
[file /opt/lmi/src/lmi/authenticity.cpp, line 287]

---------------------------
OK   
---------------------------

Ultimately, I fixed the expiry dates in 'workhorse.make' to align 
with the current practice for end-user packages:

/opt/lmi/src/lmi[0]$diff -U 3 workhorse.make_DEFAULT workhorse.make
--- workhorse.make_DEFAULT      2010-04-22 11:29:44.513212000 -0400
+++ workhorse.make      2010-05-13 09:41:32.000000000 -0400
@@ -924,9 +924,8 @@

 fardel_date_script := \
   d0=`$(DATE) +%Y-%m-01`; \
-  d1=`$(DATE) --utc --date="$$d0 + 1 month         " +%s`; \
-  d1=`$(DATE) --utc +%s`; \
-  d2=`$(DATE) --utc --date="$$d0 + 2 months - 1 day" +%s`; \
+  d1=`$(DATE) --utc --date="$$d0 + 1 month + 1 day      " +%s`; \
+  d2=`$(DATE) --utc --date="$$d0 + 2 month + 1 day      " +%s`; \
   j1=`expr 2440587 + $$d1 / 86400`; \
   j2=`expr 2440587 + $$d2 / 86400`; \
   echo -n "$$j1 $$j2" >expiry; \
@@ -948,8 +947,10 @@
   $(wildcard $(bin_dir)/product_files$(EXEEXT)) \
   $(extra_fardel_binaries) \

-fardel_files := \
+extra_fardel_files := \
   $(addprefix $(data_dir)/,$(shared_data_files)) \
+
+fardel_files := \
   $(data_files) \
   $(help_files) \
   $(extra_fardel_files) \

Rerunning 'make fardel' with the updates to 'workhorse.make', 
the 'lmi-20100513T1342Z' package is exactly the same as 
'lmi-20100513T1306Z', except the expiry is now as I expect:

2455349 2455379

which coverts to the appropriate begin-date:

JD 2455349.00000 is
CE 2010 June 01 12:00:00.0 UT  Tuesday

and end-date:

JD 2455379.00000 is
CE 2010 July 01 12:00:00.0 UT  Thursday

Using the modified 'workhorse.make', I ran the custom scripts 
and compared the result against manually-created packages. 
No unexpected differences were observed.

---------------------------------------------------------
This e-mail transmission may contain information that is 
proprietary, privileged and/or confidential and is
intended exclusively for the person(s) to whom it is
addressed. Any use, copying, retention or disclosure by
any person other than the intended recipient or the
intended recipient's designees is strictly prohibited. If
you are not the intended recipient or their designee,
please notify the sender immediately by return e-mail and
delete all copies.
---------------------------------------------------------