Chimera uses apk-tools (Alpine Package Keeper) as its system package
manager. Since Chimera uses the next-generation version 3 of the package
manager which Alpine is not yet using, there are some differences.
Additionally, there are some things to currently keep in mind because of Chimera being in an early state.
Basic usage
There is only one command, apk. Everything you might want to do is
a subcommand of it. There is in general a --help for every command.
To cover the basics, this is how you refresh the index:
# apk update
This is how you install something:
# apk add linux
This is how you remove something:
# apk del bash
This is how you upgrade your system:
# apk upgrade
There is also the --available flag for apk upgrade, which was
formerly recommended. It is no longer necessary to use this flag
in most cases, with the default --latest flag being the correct
one.
This is because Chimera now increments revision numbers, which
means it is not necessary to force the versions from repository
anymore. It may still be a good idea to run it every once in a
while, e.g. when a package gets downgraded, but be careful with
it, as it may result in some unintended consequences (e.g. packages
that installed themselves through install_if will get removed if
they are not found in any repository).
If updates introduce some file conflicts, which may happen this early in the development cycle (but will not happen once more stable, at least not intentionally), this will usually solve it:
# apk fix
You can also use apk fix to reinstall packages.
To search for a package in the repositories:
# apk search firefox
Virtual packages
You can also install packages by virtual names instead of by their real
names. Several things follow a standard convention for virtual provider
names: commands, shared libraries and pkg-config files. This convention
consists of a prefix (cmd:, so:, pc:) plus the name.
That means if you want to add the package that provides a command foo,
you can simply add it as it is:
# apk add cmd:foo
Base packages
Chimera has flexible base package splitting. There are the following main base packages:
base-bootstrapbase-minimalbase-corebase-fullbase-desktop
Each adds something more to the previous. The base-bootstrap package is a
minimal setup primarily intended for containers. The others may be bootable,
but it is recommended that most users always install base-desktop or at
least base-full unless you really know what you are doing.
The base packages never install a kernel, as that is separate. There are also
various device-specific base packages, such as base-rpi for Raspberry Pi
or base-steamdeck for the Steam Deck.
The base packages themselves do not depend on anything, instead they act as hints for the package manager to auto-install more fine-grained metapackages, such as:
base-core-fsbase-core-netbase-core-miscbase-full-firmware
and so on. For the full list, read the templates in cports or you can use
apk search:
$ apk search -r -e base-core
The reason for this is so that portions of the base system can be easily
masked in case some dependencies are not needed. For instance, if you want
a desktop environment and don’t want GNOME, you can for your convenience
install base-desktop but exclude the GNOME part:
# apk add base-desktop '!base-desktop-gnome'
This will install desktop support packages, such as GPU drivers, but not the GNOME packages; you can then install whatever else you like.
Read about the world for details of how masking works.
Repositories
By default, you will get packages from the main repository. However,
Chimera also has packages in the contrib and user repositories, which
contain extra software unsuitable for main. This includes a large amount of
non-default GUI software, for instance (e.g. additional web browsers).
The repositories are essentially tiered; contrib contains most of the
packages and is of similar quality to main. The user repository has
software that does not meet the general criteria regarding stable versioning,
dependency vendoring, and so on. That means software in user may not be
of the same quality level as software in contrib. Software in user may
additionally not be available on all tier 1 architectures.
You do not need to manually change any config files to enable these. The simplest way to get it is the following:
# apk add chimera-repo-contrib
# apk add chimera-repo-user
Afterwards simply refresh your indexes.
Debug packages
For most packages, there are debug symbols in a separate repository. When debugging something packaged by Chimera, installing debug symbols may help get better information.
You can enable them as follows:
# apk add chimera-repo-main-debug
# apk add chimera-repo-contrib-debug
# apk add chimera-repo-user-debug
After that, refresh your indexes. The debug packages are suffixed with -dbg.
Cache and interactive mode
By default, there is cache set up, with /var/cache/apk being where the
cached packages are stored.
If you wish to change this path, first mask the cache provider:
# apk add '!apk-tools-cache'
Then you can symlink /etc/apk/cache to a path of your choice.
The package manager is also interactive by default, i.e. it will ask you
to confirm before installing or removing any packages. It is recommended
not to turn this off, as it can prevent unintended changes into your
system (and it can always be overridden with --no-interactive on the
command line).
If you still wish to make the package manager non-interactive, mask the provider:
# apk add '!apk-tools-interactive'
Read about the world for details of how masking works.