Comparison with other distros
Introduction
Even if Alpine is designed to run from ram, it has some similarities in package management with both Gentoo and Debian. This page is supposed to show those differences and help Debian and Gentoo users to use Alpine.
The page was originally copied from: http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian
Package management
Where Gentoo has portage and emerge and Debian has, among others, apt, Alpine uses apk-tools. This compares how you use apk-tools in comparation to apt-get/aptitude and emerge.
Note that Gentoo is source based, just like ports in FreeBSD is while Debian uses pre-compiled binaries. Alpine is compiled using Gentoo portage but Alpine itself uses its own apk-tools binary package that are more similar FreeBSD's binary packages.
Updating package database
Gentoo will update the build-from-source scripts and are the updating of the database is takes much more time that updating the database for Debian or Alpine.
Alpine
apk_fetch -u
Gentoo
emerge --sync
Debian
aptitude update
Showing available updates
Show what packages that have an update available:
Alpine
apk_version -v
or:
apk_version -v -l '<'
Gentoo
emerge --deep --update --pretend world
Debian
aptitude upgrade --simulate
Update a particular package
Alpine
apk_add -u package1 package2
Debian
aptitude install package1 package2
Gentoo
emerge --update package1 package2
Installing packages
Alpine
apk_add package1 package2
Gentoo
emerge package1 package2
Debian
apt-get install package1 package2
Debian source compile:
apt-get build-dep package1 apt-get source package1
(optional: customize the build by modifying the debian/rules makefile) (or set environmental variables like DEB_BUILD_OPTIONS) (note that this will make your bug reports invalid to the maintainer)
dpkg-buildpackage -rfakeroot -uc -b dpkg -i generatedpackagename
Simplified source compile:
apt-get build-dep package1 apt-get -b source package1
(the packages are automatically generated using the -b switch above)
Note: This process can be used to backport packages from testing and unstable by simply adding their respective source repositories to sources.list, which is similar to adding ~x86 to package.keywords in Gentoo. This is explored further in "arch and repositories" below.
Reinstall a particular package
Alpine
apk_delete package1 && apk_add package2
or:
apk_add -f package1 package2
Gentoo
emerge --oneshot package1 package2
Debian
apt-get install --reinstall package1 package2
Note: You rarely need to reinstall a package on Debian
Searching package database
Alpine
Alpine will only search package names.
apk_fetch -lv | grep searchword
Gentoo
To search the package names and descriptions:
emerge --searchdesc searchword
Note: On Gentoo, it's actually much better to install and use either the esearch package or the eix package to do a search. You use them like this:
eix searchword
or
esearch searchword
Debian
apt-cache search searchword
Both emerge and apt-cache search support regular expressions.
To get the long package information on Debian (searching only in package names):
apt-cache search --full --names-only searchword
Removing packages
Alpine
apk_delete package1 package2
To also remove unused dependencies:
apk_delete -R package1 package2
apk_delete will remove configuration files without asking any questions. Make sure you have backups of your configuration files. (Using rcs might be an idea)
You will mostly like to take a quick look at the dependencies before you remove packages recursively.
To see dependencies for a package, use:
apk_info -R package1 package2
To see if package is required by other packages (is a dependency for another packages), use:
apk_info -r package1
Gentoo
emerge --unmerge package1 package2
Debian
apt-get remove package1 package2
or to remove along with all configuration files
apt-get remove --purge package1 package2
Only downloading packages
This can be useful e.g. if you're on a dial-up connection and want to download everything first and install later.
Alpine
apk_fetch package1 package2
Gentoo
emerge --fetchonly package1 package2
Debian
apt-get install --download-only package1 package2
Cleaning up downloaded packages
Compressed packages that were downloaded for installation can easily consume gigs of hdd space.
Alpine
Alpine will clean up package automatically unless APK_KEEPCACHE is set to "yes" in /etc/apk.conf. To do it manually if it is set:
rm /var/cache/packages/*
Gentoo
rm -rf /usr/portage/distfiles/*
To only remove outdated packages you will need to install the gentoolkit package and use eclean:
eclean distfiles
Cleaning temporary files from emerging packages:
rm -rf /var/tmp/portage/*
Debian
apt-get clean
Only remove outdated packages:
apt-get autoclean
Reverse dependencies
Alpine
apk-tools will take care of reverse dependencies.
Gentoo
Reverse dependencies are a major drawback of Gentoo's current portage implementation: It does not take care of them at all at the moment. This means that you can uninstall packages needed by others without being warned about it. E.g. you can remove the x server package without portage warning you that kde (which you have installed as well) depends on it. This way you can actually break your entire system (e.g. by removing glibc).
revdep-rebuild
can fix broken dependencies broken by emerge --depclean
Debian
Reverse dependencies are taken care of by dpkg.
Runlevel & Initscripts
Runlevels work pretty conventionally on Debian. On Alpine and Gentoo, they are a bit different.
Directories and files
In Debian runlevels are named conventionally (0-6 and S). They are represented by directories in /etc/ called rc*.d (when the default sysv-rc boot loader package is installed; file-rc can be installed instead, and then the relevant file is runlevel.conf).
- /etc/rc0.d
- /etc/rc1.d
- /etc/rcS.d
- /etc/rc2.d
- /etc/rc3.d
- /etc/rc4.d
- /etc/rc5.d
- /etc/rc6.d
In Gentoo, runlevels have the same names, but these are mapped to more self explanatory ones (in /etc/inittab): "boot", "default", "nonetwork", with the option to add more. The directories that represent them are in /etc/runlevels/:
- /etc/runlevels/boot
- /etc/runlevels/default
- /etc/runlevels/nonetwork
In Gentoo, if a service is not explicitly started in a runlevel, it is stopped when switching to that runlevel! There is no explicit stopping of runlevels as in Debian (/etc/rc?.d/K??service).
In both Debian and Gentoo, which things are started (and stopped) in which runlevels is controlled by links in the runlevel directories to scripts in /etc/init.d/, e.g.: gentoo
$ ls -l /etc/runlevels/boot/hostname lrwxrwxrwx 1 root root 20 Mar 25 2004 /etc/runlevels/boot/hostname -> /etc/init.d/hostname
Debian
$ ls -l rcS.d/S40hostname.sh lrwxrwxrwx 1 root root 21 2004-11-07 00:19 rcS.d/S40hostname.sh -> ../init.d/hostname.sh
TODO: Alpine
Runlevel management
To manage which things to start in which runlevels, use the following commands:
Alpine
To see current status of services in runlevels, do:
rc_status
To add sshd to default runlevel, do:
rc_add -k sshd
The -k option will make sure sshd is stopped when shutting down or reboot. To remove sshd from all runlevels do:
rc_delete sshd
Gentoo
rc-update
To add the cupsd to the default runlevel, do:
rc-update add cupsd default
To remove alsasound from the boot runlevel, do:
rc-update del alsasound boot
Also see this wiki page about gentoo runlevel management with rc-update
Debian
update-rc.d
Configure cupsd to be started in runlevels 2, 3, 4, 5, and stopped in 0, 1, 6, with sequence code 20:
update-rc.d cupsd start 20 2 3 4 5 . stop 20 0 1 6 .
or simply:
update-rc.d cupsd defaults
Remove cupsd from all runlevels:
update-rc.d -f cupsd remove
Config Files
/etc/make.conf and use flags
While in gentoo there are a large number of configuration files which exist to control the behaviour of the package management system. There are comparatively fewer in Debian, as there is no need to dictate how to compile software which is downloaded and tweak / alter this purpose. In gentoo, the file /etc/make.conf is used for much configuration; this includes USE flags, which influence which elements of packages are compiled, and which libraries to build support for - common USE flags (USE or -USE to specifically negate support) include 'gtk gnome' for gnome users (and a corresponding -qt -kde -arts) and 'qt kde arts' for kde users. A gentoo user's complete set of use flags may look something like this:
USE="-kde -arts -qt xv truetype bluetooth crypt slang readline gpm berkdb mmx gdbm tcpd pam libwww ssl nls ethereal perl python esd gif imlib sdl oggvorbis mpeg gnome gtk X motif opengl avi png tiff nptl pcmcia nptl ldap eds"
arch and repositories
Gentoo
Also in /etc/make.conf is the ACCEPT_KEYWORDS setting, with (for an X86-based processor) two settings, x86 for stabler packages, and ~x86 for bleeding edge packages. It is however not recommended to make this change in /etc/make.conf. Rather configure this per-package in /etc/portage/package.keywords. It's enough to put a line into that file naming the package (for example 'app-foo/bar'). That file might look like this:
app-crypt/gpg-agent app-text/docbook-xsl-stylesheets =app-text/docbook-xml-dtd-4.3-r1
The last line says, that only version 4.3-r1 should be unmasked. Older and newer versions will still be ignored.
Note for non-x86 users: The keywords x86 and ~x86 can of course be replaced by sparc and ~sparc for example.
Debian
Setting this in Debian is slightly more complicated, and is accomplished by setting different 'repositories' in /etc/apt/sources.list - along with which 'tree' to use for packages; in debian, these are stable, testing, and unstable. An /etc/apt/sources.list file for a debian testing user may look something like this:
deb http://mirrors.kernel.org/debian testing main non-free contrib deb ftp://ftp.nerim.net/debian-marillat testing main deb http://security.debian.org testing/updates main contrib non-free
Alternatively, /etc/apt/sources.list can contain any number of repositories for any trees, and a default tree (this can be overridden using the -t switch on the command line) in /etc/apt/apt.conf:
APT::Default-Release "testing";
Per-package settings go in /etc/apt/preferences, somewhat like Gentoo's /etc/portage/package.keywords.
Network
Alpine
Alpine uses /etc/network/interfaces, just like Debian. The main reason is because this is the way busybox does it.
/etc/network/interfaces:
auto eth0 iface eth0 inet static address 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255 auto eth0:0 iface eth0:0 inet static address 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 # etc.
Gentoo
/etc/conf.d/net:
config_eth0=( "192.168.1.100 netmask 255.255.255.0"
"192.168.2.100 netmask 255.255.255.0" )
routes_eth0=( "default via 192.168.1.1" )
Note that this has changed recently. For more information please refer to http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=4
Debian
/etc/network/interfaces:
auto eth0 iface eth0 inet static address 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255 auto eth0:0 iface eth0:0 inet static address 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 # etc.
Comparison chart
 Please feel free to help us make an up-to-date version. (Discuss) |
This chart shows how some standard things are done in (older versions of) Alpine compared to other distributions.
| Action | Alpine 1.9 | Alpine 1.8 | Arch Linux | Gentoo | Debian/Ubuntu |
|---|---|---|---|---|---|
| Update package database | apk update |
apk_fetch -u |
pacman -Sy |
emerge --sync |
aptitude update |
| Showing available updates | apk version -l '<' |
apk_version -v -l '<' |
emerge --deep --update --pretend @world |
aptitude upgrade --simulate | |
| Update a particular package | |||||
| Installing packages | |||||
| Reinstall a particular package | |||||
| Searching package database | |||||
| Removing packages | |||||
| Only downloading packages | |||||
| Cleaning up downloaded packages | |||||
| Reverse dependencies |