At the moment, we rely on the `LPCONFIG` variable (implicitly inherited
by these hook scripts from the parent process) for this. However, in a
charmed deployment, `LPCONFIG` is set purely based on the charm name,
and is the same across production and non-production deployments of the
same charm. As a result, we can't rely on it for this any more.
An approach that we've taken in a few other places is to conditionalize
behaviour based on the main site's hostname. This has the advantage
that the condition is spelled using an existing user-visible name (e.g.
"launchpad.net") rather than an internal codename that you're just
expected to know (e.g. "production" or the various values of
`LPCONFIG`). To support this, I've invented the `SITE_NAME` environment
variable, which the publisher now sets to the main site's hostname when
running its hook scripts.
charm: Sync ftpmaster charm-wheels/ols-layers with other charms
Compare https://git.launchpad.net/launchpad/commit?id=1099f303dc. (The
changes to `build-snaps`, `build-packages`, and
`reactive-charm-build-arguments` from that commit already appear to be
in place in these two charms as well.)
Expand relative directories in PublisherConfig.root_dir
The `PublisherConfig` table is designed quite strangely: it includes a
`root_dir` column which stores the root file system path at which each
distribution is published. This is a problem for charmed deployments of
the primary Ubuntu and copy archive publishers, because our charms don't
use the same base directory as our legacy deployments.
Fortunately, all the existing paths are absolute, so we have a
reasonable migration path that doesn't require us to change the database
at the same time as migrating to a new deployment. Interpret relative
paths in `PublisherConfig.root_dir` as being relative to a new
`config.archivepublisher.archives_dir` configuration entry; we can set
this to appropriate values in both legacy and charmed deployments, and
then change existing production database rows to use relative paths.
