Project

General

Profile

Feature #7330

Updated by Brett Smith over 8 years ago

The after-install script should, in the usual case, perform all the same actions that arvados-sso-server-upgrade.sh currently performs.    However, there are some expected implementation differences: 

 * Be prepared to be called "with dpkg's calling arguments":http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-mscriptsinstact or "rpm's calling arguments":http://www.rpm.org/max-rpm/s1-rpm-inside-scripts.html#S2-RPM-INSIDE-ERASE-TIME-SCRIPTS.    If some actions don't make sense in some calling scenarios, make sure they're skipped. 
 * Instead of introspecting the system to determine whether we're on Debian or Red Hat, use the calling arguments so we get that information directly from the packaging system, which should be more reliable. 
 * Add a before-remove script.    When the package is being downgraded, run all the database migrations down.    [TBD: How do we figure out which migrations to run down?    There's not necessarily any correlation between package version timestamps and migration timestamps, since the latter just reflect when the developer started working on them.    But we can't do this in an after-remove script, because the migration code might be gone by then.] 
 * Instead of copying @/etc/arvados/sso/*.yml@ to @/var/www/arvados-sso/current/config@, we should make symlinks in @/var@ to files in @/etc@, so the copies don't get out of sync with the canonical versions.    If there's a way to do this directly with fpm, feel free to great; do that, since it will probably be more reliable. that.    But if nothing else, you can Otherwise, make the symlinks in the after-install script, and add a small before-remove script to remove them in the before-remove script when the last version of the package is being removed (so they don't interfere with removing all of @/var/www/arvados-sso@). 
 * Update our install guide to remove references to running @arvados-sso-server-upgrade.sh@. /var/www/arvados-sso).

Back