[LON-CAPA-admin] localauth-std.pm

[Scott Harrison]

> Actually I tried to make this easy for everyone,

I enjoy making things difficult :).

> The std localauth contains these lines:
> # ----START LOCAL CHANGES HERE ----- DON'T DELETE THIS LINE
> # ----END LOCAL CHANGES HERE ----- DON'T DELETE THIS LINE
> 
> I had hoped the installation process would eventually make use of
> this, (I.e. perserver what ever is between the START and END but paste
> that into the new versions START END section)

And we're off now with another lengthy reply....

So, I guess there are two scenarios:

* aggressive intelligence: which copies and pastes local changes
  from one file into another

* passive intelligence: which knows that some files are subject to
  special treatment and,
  ordinarly maintains a softlink from the NEEDED_FILE to the NEEDED_FILE-std
  but will otherwise warn the user if the NEEDED_FILE is different than
  a new release of NEEDED_FILE-std

I would suggest:
* creating a LPML file metacategory called "featherglove"
* the default mode will be to, as you desire, be aggressively intelligent
* But, for the meticulous and the paranoid (and the installation testers)
  I would strongly advocate a passive intelligence Makefile parameter
  (e.g. make PARANOIA=1 install or ./UPGRADE_paranoid and ./UPGRADE).

For instance, if a large institution is running all their courses off
of one server, maybe the system admin is paranoid.  And, I think paranoia
is a very good thing for system admins who choose to be careful.
I don't want to abandon or ignore admins who want to be paranoid
since, in some ways, they really are the lifeblood of LON-CAPA.

However, if a system admin is running dozens of LON-CAPA servers,
then after backing things (backup-and-restore is kinda working now
in the Makefile, but I very much need to make it proveably workable
before announcing it as a public feature)... they can try out an
aggressive update on one machine, and if it works, just aggressive
update all other machines.

I know YOU do this (test out the installation before fully releasing it),
but it wouldn't hurt to support this model for others so as
to be doubly reliable.

I almost don't care how simple or complex the final solution here is,
but I greatly want to avoid anything that introduces a long time window
of flux and confusion with the packaging and installation mechanism for,
I think, obvious reasons.

I think a passive-only installation mechanism is superior to an
aggressive-only installation mechanism.  However, unlike most RPMs
out there, I think we should support both mechanisms and allow
the system admin to clearly and simply specify which of the two
options by which the upgrade behaves.  And your mechanism should
be the default since it is most efficient.

Regards,
Scott

> 
> 
> 
> -- 
> guy at albertelli.com          BM: n^20 t20 z20 qS 
> Guy Albertelli -7-7-7-  O-
>     In the force if Yoda's so strong, construct a sentence
>     with words in the proper order then why can't he?
> _______________________________________________
> LON-CAPA-admin mailing list
> LON-CAPA-admin at mail.lon-capa.org
> http://mail.lon-capa.org/mailman/listinfo/lon-capa-admin