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.
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.
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.