I can’t seem to find anything that explains in plain English how auto-aliasing works.
We maintain PostgreSQL snap packages and PostgreSQL project releases several major versions at a time. Thus, there are about 4 PostgreSQL snap packages and each of those has a pretty much identical set of apps.
It is not uncommon for people to want to run two or more different versions on the same host and I’d like to know for sure what is going to happen if two or more packages provide auto-aliases.
I know from my experience of setting manual aliases that an alias has to be unique, and I’d guess the same rule applies to auto-aliases.
However, I’m not entirely sure how far this auto-aliasing idea has been taken. Does it mean that aliases will be immediately enabled during installation of a snap package? Or a user needs to enable them afterwards manually anyway?
Assuming auto-aliasing means aliases are enabled when a package is installed, what is going to happen when a user installs another package with the same app and the same aliases? E.g. PostgreSQL 9.6 packages is already installed and there is “postgresql96.psql psql” alias. A user installs PostgreSQL 9.3 which also has an auto-alias for “postgresql93.psql psql”.
Will the installation of the package fail? Will the package be installed regardless but auto-alias won’t be enabled?
Please, elucidate and/or point to relevant documentation.
the installation will fail explaining there’s an alias conflict.
On master (2.27+) snap install --unaliased can be used to install without enabling the aliases so without incurring the conflict,
then there’s snap prefer <snap> (already in 2.25) to switch around which snap gets the aliases enabled.
We plan to have a shortcut snap install --prefer to instead disable the current aliases and give them to the being-installed snap in one go, but it is not yet implemented.
Note that even if a given version is not the one with aliases setup for it, it may still be used via the full command names.
Tracks are a mechanism to have different lines of releases. Postgres might have a “9.3” and a “9.6” track for example, each with the respective patch releases. So someone might do snap install --channel=9.3/stable to pick the latest revision released in the specific track.
I get the general idea but when I look at Launchpad package configuration page (this is where we build the packages) I don’t really see how this is going to work.
Looking at the “Create a new snap package” page, there are several form fields to fill:
Name:
Registered store package name:
Risk:
Track:
Let’s take PostgreSQL version 9.3.17 for example.
My guess is you expect this:
Name: postgresql (perhaps postgresql-9.3.17 would be better?)
Registered store package name: postgresql
Risk: stable
Track: 9.3
Consequently, for PostgreSQL 9.6.1 it should be:
Name: postgresql (similarly, postgresql-9.6.1 would be a better name?)
Registered store package name: postgresql
Risk: stable
Track: 9.6
and so on.
But I don’t see where the actual version number comes into play. Is it derived from corresponding entry in snapcraft.yaml?
Also, snap (2.25) install command offers only --revision and --channel but nothing, it seems, pertaining to the concept of the tracks.
Basically, what I’m trying to figure out is how one would configure Launchpad and how one would install a specific version of the package that belongs to a specific track.
I would appreciated it if somebody explained how this is supposed to work.
The documentation I mentioned in the prior post explains a bit better how tracks and channels in general work. The track is part of the channel instead of being an isolated idea, so you provide it as part of the –channel flag as well.
