Alpine Linux - User contributions [en]

Talk:Main Page

2023-08-15T06:10:19Z

Winny: /* Give everyone write access */

== Put important content at top? ==
Hey, looks like I can't edit this page. I was wondering if it would be possible to move the navigation and welcome section to the top of the page. The warning about the license change is important, however, I don't think that's what most users come to the wiki to read. — [[User:Winny|Winny]] ([[User talk:Winny|talk]]) 17:53, 15 August 2022 (UTC)

== Give everyone write access ==

I think you'd find the quality of this page will increase significantly, if you all permit contributions. [[User:Winny|Winny]] ([[User talk:Winny|talk]]) 06:57, 11 April 2023 (UTC)

:Looks like contributions are allowed now. How can this page be improved? [[User:Bbbhltz|bbbhltz]] ([[User talk:Bbbhltz|talk]]) 11:00, 20 April 2023 (UTC)

::Any thoughts on this [[Sandbox#Main_Page_Proposal|Proposal]]? Keep in mind I only learned how to make tables today. Those icons from 2010 are perfectly fine, but we could use something like https://tabler-icons.io/ for simpler look. [[User:Bbbhltz|bbbhltz]] ([[User talk:Bbbhltz|talk]]) 12:23, 22 April 2023 (UTC)

:::Thanks for giving write access. I made an edit designed to de-emphasize the greeting (which is not what people are looking for when navigating this page). I created one header to separate the "project summary"+greeting from the navigation links and miscellaneous (clutter drawer) links. Hope you like it. If not, please do not simply revert, put in some effort too, this homepage could be AMAZING :D. PS 8bbhltz I didn't see icons on that proposed page - so it's all just words on my screen, so I'm not sure if that'd be an improvement for funneling users quickly through this page. — [[User:Winny|Winny]] ([[User talk:Winny|talk]]) 06:08, 15 August 2023 (UTC)

::::PS the home page is a WIP. Check out https://wiki.archlinux.org/ and other mediawiki-based project websites. We can learn a lot from other projects and take the shortest path to a great homepage. — [[User:Winny|Winny]] ([[User talk:Winny|talk]]) 06:10, 15 August 2023 (UTC)

Talk:Main Page

2023-08-15T06:08:12Z

Winny: /* Give everyone write access */

Main Page

2023-08-15T06:01:42Z

Winny: use header to demarcate. been referring to other wikis for landing page ideas

__NOEDITSECTION__
__NOTOC__

''' Welcome to Alpine Linux Wiki! '''

'''[http://alpinelinux.org/about Alpine Linux]''' is a security-oriented, lightweight Linux distribution based on [https://musl.libc.org/ musl libc] and [https://busybox.net Busybox].

Here is a [[Alpine Linux:Overview|more detailed overview]] of what makes our distribution distinctive; and a [[comparison with other distros]].

== How can we help you? ==

{|style="margin: 1em auto 1em auto"
|style="width:64px;"|[[image:hdd_mount.svg|64px|link=Installation]]
|'''[[Installation]]''' Installing Alpine Linux
|[[image:filetypes.svg|64px|link=Alpine Linux:FAQ]]
|'''[[Alpine Linux:FAQ|FAQ]]''' Frequently Asked Questions
|[[image:bookcase.svg|64px|link=Alpine Linux:Glossary]]
|'''[[Alpine Linux:Glossary|Glossary]]'''
|-
|[[image:package_edutainment.svg|64px|link=Tutorials and Howtos]]
|'''[[Tutorials and Howtos]]''' Basic and advanced configuration tasks
|[[image:package_system.svg|64px|link=Category_talk:Developer_Documentation]]
|'''[[Category talk:Developer Documentation|Developer Documentation]]''' Alpine Linux Development
|[[image:kuser.svg|64px|link=Alpine Linux:Contribute]]
|'''[[Alpine Linux:Contribute|Contribute]]''' Contribute to Alpine Linux
|}

* [https://alpinelinux.org/releases Current releases] (latest is {{AlpineLatest}})
* [[Alpine Linux:Listings|Links to other sites with information about Alpine]]

For licensing on any contributions, see the [[Alpine Linux:Privacy policy|Privacy Policy]].

Main Page

2023-08-15T05:57:31Z

Winny: The size of text impacts the importance. I don't think the greeting is any more important than the links below. This is a landing page after all - it's not really an "article" per se. wiki.archlinux.org also does not have a header at the start of theil landing page, so others have done this too.

__NOEDITSECTION__
__NOTOC__

''' Welcome to Alpine Linux Wiki! '''

'''[http://alpinelinux.org/about Alpine Linux]''' is a security-oriented, lightweight Linux distribution based on [https://musl.libc.org/ musl libc] and [https://busybox.net Busybox].

Here is a [[Alpine Linux:Overview|more detailed overview]] of what makes our distribution distinctive; and a [[comparison with other distros]].

 
{|style="margin: 1em auto 1em auto"
|style="width:64px;"|[[image:hdd_mount.svg|64px|link=Installation]]
|'''[[Installation]]''' Installing Alpine Linux
|[[image:filetypes.svg|64px|link=Alpine Linux:FAQ]]
|'''[[Alpine Linux:FAQ|FAQ]]''' Frequently Asked Questions
|[[image:bookcase.svg|64px|link=Alpine Linux:Glossary]]
|'''[[Alpine Linux:Glossary|Glossary]]'''
|-
|[[image:package_edutainment.svg|64px|link=Tutorials and Howtos]]
|'''[[Tutorials and Howtos]]''' Basic and advanced configuration tasks
|[[image:package_system.svg|64px|link=Category_talk:Developer_Documentation]]
|'''[[Category talk:Developer Documentation|Developer Documentation]]''' Alpine Linux Development
|[[image:kuser.svg|64px|link=Alpine Linux:Contribute]]
|'''[[Alpine Linux:Contribute|Contribute]]''' Contribute to Alpine Linux
|}

* [https://alpinelinux.org/releases Current releases] (latest is {{AlpineLatest}})
* [[Alpine Linux:Listings|Links to other sites with information about Alpine]]

For licensing on any contributions, see the [[Alpine Linux:Privacy policy|Privacy Policy]].

Talk:Main Page

2023-04-11T06:57:50Z

Winny: /* Give everyone write access */ add sig

Talk:Main Page

2023-04-11T06:57:02Z

Winny: /* Give everyone write access */ new section

Talk:Main Page

2023-04-11T06:54:09Z

Winny: Hmm, I think the problem was addressed, but the sentiment still exists ;). Undo revision 23130 by Winny (talk)

Talk:Main Page

2023-04-11T06:52:21Z

Winny: good job

Comparison with other distros

2022-08-15T18:28:52Z

Winny: /* Comparison chart/Rosetta Stone */ mention additional resource

Even if Alpine is designed to run from RAM, it has some similarities in package management with other distributions. This page outlines those similarities and differences, to help new users use Alpine and understand the differences between Alpine and other distributions.

{{Note|The page was originally copied from: [https://web.archive.org/web/20070911124125/http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian]}}

 

= Package management =
Where Gentoo has portage and emerge; Debian has, among others, apt; Alpine uses apk-tools. This section compares how apk-tools is used, in comparison to apt and emerge.

== Updating package database ==
Gentoo will update the build-from-source scripts and the updating of the database takes much more time than updating the database for Debian or Alpine.

'''Alpine'''
apk update

'''Debian'''
apt update

'''Gentoo'''
emerge --sync

== Showing available updates ==
Show which packages have an update available:

'''Alpine'''
apk version -v
or:
apk version -v -l '<'

'''Gentoo'''
emerge --deep --update --pretend @world

'''Debian'''
apt upgrade --simulate

== Updating a particular package ==
'''Alpine'''
apk add -u package1 package2
or
apk upgrade package1 package2
'''Debian'''
apt install package1 package2
'''Gentoo'''
emerge --update package1 package2

== Installing packages ==
'''Alpine'''
apk add package1 package2

For source compile, see the [[Aports tree]] and the [[abuild]] tool.

'''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 the "Architectures and repositories" section below.

== Reinstalling particular packages ==
'''Alpine'''
apk del package1 package2 && apk add package1 package2
or:
apk fix 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 the package database ==
'''Alpine'''

Alpine will only search package names.
apk search searchword

'''Gentoo'''

To search the package names and descriptions:
emerge --searchdesc searchword
'''Note:''' On Gentoo, it's actually much better to install and use the eix package to do a search. You use them like this:
eix 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 del package1 package2
''apk del'' will remove configuration files when the ''--purge'' flag is used. Make sure you have backups of your configuration files.

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 package2

'''Gentoo'''

The correct way to remove packages on gentoo.
emerge --depclean package1 package2

In case you know what you're doing, you may skip dependency checks and potentiality leave your system in broken state.
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 gigabytes of storage space.

'''Alpine'''

Alpine will clean up packages automatically.

'''Gentoo'''

The following command will leave ''/var/cache/distfiles/'' folder intact, while deleting all children.

find /var/cache/distfiles/ -mindepth 1 -delete

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

Recent versions of portage include library tracking and preservation with the preserved-libs feature. Portage will notify you to run {{Cmd|emerge @preserved-rebuild}} to help rebuild binaries that might otherwise become broken.

'''Debian'''

Reverse dependencies are taken care of by dpkg.

= Runlevel & Initscripts =
Runlevels work pretty conventionally on Debian (see details: [http://archive.fo/ZdZIz systemd]{{dead link}}). On Alpine and Gentoo, they are a bit different.

== Directories and files ==
{{Obsolete|Debian now uses systemd.}}

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

'''Alpine'''

In Alpine, runlevels work like they do in Gentoo:

* /etc/runlevels/boot
* /etc/runlevels/default
* /etc/runlevels/sysinit
* /etc/runlevels/nonetwork
* /etc/runlevels/shutdown

== 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-update add sshd default
To remove sshd from all runlevels do:
rc-update del 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 [http://gentoo-wiki.com/Rc-update gentoo runlevel management with rc-update]

{{Obsolete|Debian now uses systemd.}}

'''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/portage/make.conf and use flags ==
While in Gentoo there's a large number of configuration files which 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 it. In Gentoo, the file /etc/portage/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"'''

== Architectures and repositories ==
'''Gentoo'''

Also in /etc/portage/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/portage/make.conf. Rather configure this per-package in /etc/portage/package.accept_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, similar to Debian. Alpine uses busybox's implementation by default.

''/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'''

Gentoo uses ''netifrc''. This packages is also available in the edge community repository. (Use on Alpine at your own risk.)

''/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/Rosetta Stone =

This chart shows how some standard things are done in Alpine compared to other distributions. See also the [https://wiki.archlinux.org/title/Pacman/Rosetta Pacman Rosetta].

{| cellpadding="5" border="1" class="wikitable"
|-
! Action
! Alpine ([https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management apk])
! Arch Linux ([https://wiki.archlinux.org/index.php/Pacman pacman])
! Gentoo ([https://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1 emerge])
! Debian/Ubuntu ([https://wiki.debian.org/AptCLI apt])
! Fedora/RHEL/SL/CentOS ([http://yum.baseurl.org/wiki/YumCommands yum])
! VoidLinux ([https://docs.voidlinux.org/xbps/index.html?highlight=xb#xbps-package-manager XBPS])
|-
| Update package database
| {{Cmd| apk update}}
| {{Cmd| pacman -Sy}}
| {{Cmd| emerge --sync}}
| {{Cmd| apt update}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -S}}
|-
| Showing available updates
| {{Cmd| apk version -l '<'}}
| {{Cmd| pacman -Qu}}
| {{Cmd| emerge --deep --update --pretend @world}}
| {{Cmd| apt upgrade --simulate}}
| {{Cmd| yum list updates}}
| {{Cmd| xbps-install -n -u}}
|-
| Installing packages
| {{Cmd| apk add [package name]}}
| {{Cmd| pacman -S [package name]}}
| {{Cmd| emerge [package name]}}
| {{Cmd| apt install [package name]}}
| {{Cmd| yum install [package name]}}
| {{Cmd| xbps-install [package name]}}
|-
| Update all installed packages
| {{Cmd| apk upgrade -U -a}}
| {{Cmd| pacman -Su}}
| {{Cmd| emerge --update --deep @world}}
| {{Cmd| apt upgrade}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -u}}
|-
| Searching package database
| {{Cmd| apk search -v '[string]*'}}
| {{Cmd| pacman -Ss [string]}}
| {{Cmd| emerge --search [string]}}
| {{Cmd| apt search [string]}}
| {{Cmd| yum search [string]}}
| {{Cmd| xbps-query -Rs [string]}}
|-
| Removing packages
| {{Cmd| apk del [package name]}}
| {{Cmd| pacman -R [package name]}}
| {{Cmd| emerge --depclean [package name]}}
| {{Cmd| apt remove [package name]}}
| {{Cmd| yum remove [package name]}}
| {{Cmd| xbps-remove [package name]}}
|}

[[Category:Package Manager]]

Comparison with other distros

2022-08-15T18:27:47Z

Winny: /* Network */ cleanup

Even if Alpine is designed to run from RAM, it has some similarities in package management with other distributions. This page outlines those similarities and differences, to help new users use Alpine and understand the differences between Alpine and other distributions.

{{Note|The page was originally copied from: [https://web.archive.org/web/20070911124125/http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian]}}

 

= Package management =
Where Gentoo has portage and emerge; Debian has, among others, apt; Alpine uses apk-tools. This section compares how apk-tools is used, in comparison to apt and emerge.

== Updating package database ==
Gentoo will update the build-from-source scripts and the updating of the database takes much more time than updating the database for Debian or Alpine.

'''Alpine'''
apk update

'''Debian'''
apt update

'''Gentoo'''
emerge --sync

== Showing available updates ==
Show which packages have an update available:

'''Alpine'''
apk version -v
or:
apk version -v -l '<'

'''Gentoo'''
emerge --deep --update --pretend @world

'''Debian'''
apt upgrade --simulate

== Updating a particular package ==
'''Alpine'''
apk add -u package1 package2
or
apk upgrade package1 package2
'''Debian'''
apt install package1 package2
'''Gentoo'''
emerge --update package1 package2

== Installing packages ==
'''Alpine'''
apk add package1 package2

For source compile, see the [[Aports tree]] and the [[abuild]] tool.

'''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 the "Architectures and repositories" section below.

== Reinstalling particular packages ==
'''Alpine'''
apk del package1 package2 && apk add package1 package2
or:
apk fix 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 the package database ==
'''Alpine'''

Alpine will only search package names.
apk search searchword

'''Gentoo'''

To search the package names and descriptions:
emerge --searchdesc searchword
'''Note:''' On Gentoo, it's actually much better to install and use the eix package to do a search. You use them like this:
eix 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 del package1 package2
''apk del'' will remove configuration files when the ''--purge'' flag is used. Make sure you have backups of your configuration files.

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 package2

'''Gentoo'''

The correct way to remove packages on gentoo.
emerge --depclean package1 package2

In case you know what you're doing, you may skip dependency checks and potentiality leave your system in broken state.
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 gigabytes of storage space.

'''Alpine'''

Alpine will clean up packages automatically.

'''Gentoo'''

The following command will leave ''/var/cache/distfiles/'' folder intact, while deleting all children.

find /var/cache/distfiles/ -mindepth 1 -delete

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

Recent versions of portage include library tracking and preservation with the preserved-libs feature. Portage will notify you to run {{Cmd|emerge @preserved-rebuild}} to help rebuild binaries that might otherwise become broken.

'''Debian'''

Reverse dependencies are taken care of by dpkg.

= Runlevel & Initscripts =
Runlevels work pretty conventionally on Debian (see details: [http://archive.fo/ZdZIz systemd]{{dead link}}). On Alpine and Gentoo, they are a bit different.

== Directories and files ==
{{Obsolete|Debian now uses systemd.}}

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

'''Alpine'''

In Alpine, runlevels work like they do in Gentoo:

* /etc/runlevels/boot
* /etc/runlevels/default
* /etc/runlevels/sysinit
* /etc/runlevels/nonetwork
* /etc/runlevels/shutdown

== 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-update add sshd default
To remove sshd from all runlevels do:
rc-update del 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 [http://gentoo-wiki.com/Rc-update gentoo runlevel management with rc-update]

{{Obsolete|Debian now uses systemd.}}

'''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/portage/make.conf and use flags ==
While in Gentoo there's a large number of configuration files which 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 it. In Gentoo, the file /etc/portage/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"'''

== Architectures and repositories ==
'''Gentoo'''

Also in /etc/portage/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/portage/make.conf. Rather configure this per-package in /etc/portage/package.accept_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, similar to Debian. Alpine uses busybox's implementation by default.

''/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'''

Gentoo uses ''netifrc''. This packages is also available in the edge community repository. (Use on Alpine at your own risk.)

''/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/Rosetta Stone =

This chart shows how some standard things are done in Alpine compared to other distributions.

{| cellpadding="5" border="1" class="wikitable"
|-
! Action
! Alpine ([https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management apk])
! Arch Linux ([https://wiki.archlinux.org/index.php/Pacman pacman])
! Gentoo ([https://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1 emerge])
! Debian/Ubuntu ([https://wiki.debian.org/AptCLI apt])
! Fedora/RHEL/SL/CentOS ([http://yum.baseurl.org/wiki/YumCommands yum])
! VoidLinux ([https://docs.voidlinux.org/xbps/index.html?highlight=xb#xbps-package-manager XBPS])
|-
| Update package database
| {{Cmd| apk update}}
| {{Cmd| pacman -Sy}}
| {{Cmd| emerge --sync}}
| {{Cmd| apt update}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -S}}
|-
| Showing available updates
| {{Cmd| apk version -l '<'}}
| {{Cmd| pacman -Qu}}
| {{Cmd| emerge --deep --update --pretend @world}}
| {{Cmd| apt upgrade --simulate}}
| {{Cmd| yum list updates}}
| {{Cmd| xbps-install -n -u}}
|-
| Installing packages
| {{Cmd| apk add [package name]}}
| {{Cmd| pacman -S [package name]}}
| {{Cmd| emerge [package name]}}
| {{Cmd| apt install [package name]}}
| {{Cmd| yum install [package name]}}
| {{Cmd| xbps-install [package name]}}
|-
| Update all installed packages
| {{Cmd| apk upgrade -U -a}}
| {{Cmd| pacman -Su}}
| {{Cmd| emerge --update --deep @world}}
| {{Cmd| apt upgrade}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -u}}
|-
| Searching package database
| {{Cmd| apk search -v '[string]*'}}
| {{Cmd| pacman -Ss [string]}}
| {{Cmd| emerge --search [string]}}
| {{Cmd| apt search [string]}}
| {{Cmd| yum search [string]}}
| {{Cmd| xbps-query -Rs [string]}}
|-
| Removing packages
| {{Cmd| apk del [package name]}}
| {{Cmd| pacman -R [package name]}}
| {{Cmd| emerge --depclean [package name]}}
| {{Cmd| apt remove [package name]}}
| {{Cmd| yum remove [package name]}}
| {{Cmd| xbps-remove [package name]}}
|}

[[Category:Package Manager]]

Comparison with other distros

2022-08-15T18:24:43Z

Winny: /* Runlevel management */ systemd

Even if Alpine is designed to run from RAM, it has some similarities in package management with other distributions. This page outlines those similarities and differences, to help new users use Alpine and understand the differences between Alpine and other distributions.

{{Note|The page was originally copied from: [https://web.archive.org/web/20070911124125/http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian]}}

 

= Package management =
Where Gentoo has portage and emerge; Debian has, among others, apt; Alpine uses apk-tools. This section compares how apk-tools is used, in comparison to apt and emerge.

== Updating package database ==
Gentoo will update the build-from-source scripts and the updating of the database takes much more time than updating the database for Debian or Alpine.

'''Alpine'''
apk update

'''Debian'''
apt update

'''Gentoo'''
emerge --sync

== Showing available updates ==
Show which packages have an update available:

'''Alpine'''
apk version -v
or:
apk version -v -l '<'

'''Gentoo'''
emerge --deep --update --pretend @world

'''Debian'''
apt upgrade --simulate

== Updating a particular package ==
'''Alpine'''
apk add -u package1 package2
or
apk upgrade package1 package2
'''Debian'''
apt install package1 package2
'''Gentoo'''
emerge --update package1 package2

== Installing packages ==
'''Alpine'''
apk add package1 package2

For source compile, see the [[Aports tree]] and the [[abuild]] tool.

'''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 the "Architectures and repositories" section below.

== Reinstalling particular packages ==
'''Alpine'''
apk del package1 package2 && apk add package1 package2
or:
apk fix 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 the package database ==
'''Alpine'''

Alpine will only search package names.
apk search searchword

'''Gentoo'''

To search the package names and descriptions:
emerge --searchdesc searchword
'''Note:''' On Gentoo, it's actually much better to install and use the eix package to do a search. You use them like this:
eix 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 del package1 package2
''apk del'' will remove configuration files when the ''--purge'' flag is used. Make sure you have backups of your configuration files.

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 package2

'''Gentoo'''

The correct way to remove packages on gentoo.
emerge --depclean package1 package2

In case you know what you're doing, you may skip dependency checks and potentiality leave your system in broken state.
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 gigabytes of storage space.

'''Alpine'''

Alpine will clean up packages automatically.

'''Gentoo'''

The following command will leave ''/var/cache/distfiles/'' folder intact, while deleting all children.

find /var/cache/distfiles/ -mindepth 1 -delete

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

Recent versions of portage include library tracking and preservation with the preserved-libs feature. Portage will notify you to run {{Cmd|emerge @preserved-rebuild}} to help rebuild binaries that might otherwise become broken.

'''Debian'''

Reverse dependencies are taken care of by dpkg.

= Runlevel & Initscripts =
Runlevels work pretty conventionally on Debian (see details: [http://archive.fo/ZdZIz systemd]{{dead link}}). On Alpine and Gentoo, they are a bit different.

== Directories and files ==
{{Obsolete|Debian now uses systemd.}}

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

'''Alpine'''

In Alpine, runlevels work like they do in Gentoo:

* /etc/runlevels/boot
* /etc/runlevels/default
* /etc/runlevels/sysinit
* /etc/runlevels/nonetwork
* /etc/runlevels/shutdown

== 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-update add sshd default
To remove sshd from all runlevels do:
rc-update del 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 [http://gentoo-wiki.com/Rc-update gentoo runlevel management with rc-update]

{{Obsolete|Debian now uses systemd.}}

'''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/portage/make.conf and use flags ==
While in Gentoo there's a large number of configuration files which 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 it. In Gentoo, the file /etc/portage/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"'''

== Architectures and repositories ==
'''Gentoo'''

Also in /etc/portage/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/portage/make.conf. Rather configure this per-package in /etc/portage/package.accept_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/Rosetta Stone =

This chart shows how some standard things are done in Alpine compared to other distributions.

{| cellpadding="5" border="1" class="wikitable"
|-
! Action
! Alpine ([https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management apk])
! Arch Linux ([https://wiki.archlinux.org/index.php/Pacman pacman])
! Gentoo ([https://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1 emerge])
! Debian/Ubuntu ([https://wiki.debian.org/AptCLI apt])
! Fedora/RHEL/SL/CentOS ([http://yum.baseurl.org/wiki/YumCommands yum])
! VoidLinux ([https://docs.voidlinux.org/xbps/index.html?highlight=xb#xbps-package-manager XBPS])
|-
| Update package database
| {{Cmd| apk update}}
| {{Cmd| pacman -Sy}}
| {{Cmd| emerge --sync}}
| {{Cmd| apt update}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -S}}
|-
| Showing available updates
| {{Cmd| apk version -l '<'}}
| {{Cmd| pacman -Qu}}
| {{Cmd| emerge --deep --update --pretend @world}}
| {{Cmd| apt upgrade --simulate}}
| {{Cmd| yum list updates}}
| {{Cmd| xbps-install -n -u}}
|-
| Installing packages
| {{Cmd| apk add [package name]}}
| {{Cmd| pacman -S [package name]}}
| {{Cmd| emerge [package name]}}
| {{Cmd| apt install [package name]}}
| {{Cmd| yum install [package name]}}
| {{Cmd| xbps-install [package name]}}
|-
| Update all installed packages
| {{Cmd| apk upgrade -U -a}}
| {{Cmd| pacman -Su}}
| {{Cmd| emerge --update --deep @world}}
| {{Cmd| apt upgrade}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -u}}
|-
| Searching package database
| {{Cmd| apk search -v '[string]*'}}
| {{Cmd| pacman -Ss [string]}}
| {{Cmd| emerge --search [string]}}
| {{Cmd| apt search [string]}}
| {{Cmd| yum search [string]}}
| {{Cmd| xbps-query -Rs [string]}}
|-
| Removing packages
| {{Cmd| apk del [package name]}}
| {{Cmd| pacman -R [package name]}}
| {{Cmd| emerge --depclean [package name]}}
| {{Cmd| apt remove [package name]}}
| {{Cmd| yum remove [package name]}}
| {{Cmd| xbps-remove [package name]}}
|}

[[Category:Package Manager]]

Comparison with other distros

2022-08-15T18:24:08Z

Winny: /* Directories and files */ systemd

Even if Alpine is designed to run from RAM, it has some similarities in package management with other distributions. This page outlines those similarities and differences, to help new users use Alpine and understand the differences between Alpine and other distributions.

{{Note|The page was originally copied from: [https://web.archive.org/web/20070911124125/http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian]}}

 

= Package management =
Where Gentoo has portage and emerge; Debian has, among others, apt; Alpine uses apk-tools. This section compares how apk-tools is used, in comparison to apt and emerge.

== Updating package database ==
Gentoo will update the build-from-source scripts and the updating of the database takes much more time than updating the database for Debian or Alpine.

'''Alpine'''
apk update

'''Debian'''
apt update

'''Gentoo'''
emerge --sync

== Showing available updates ==
Show which packages have an update available:

'''Alpine'''
apk version -v
or:
apk version -v -l '<'

'''Gentoo'''
emerge --deep --update --pretend @world

'''Debian'''
apt upgrade --simulate

== Updating a particular package ==
'''Alpine'''
apk add -u package1 package2
or
apk upgrade package1 package2
'''Debian'''
apt install package1 package2
'''Gentoo'''
emerge --update package1 package2

== Installing packages ==
'''Alpine'''
apk add package1 package2

For source compile, see the [[Aports tree]] and the [[abuild]] tool.

'''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 the "Architectures and repositories" section below.

== Reinstalling particular packages ==
'''Alpine'''
apk del package1 package2 && apk add package1 package2
or:
apk fix 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 the package database ==
'''Alpine'''

Alpine will only search package names.
apk search searchword

'''Gentoo'''

To search the package names and descriptions:
emerge --searchdesc searchword
'''Note:''' On Gentoo, it's actually much better to install and use the eix package to do a search. You use them like this:
eix 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 del package1 package2
''apk del'' will remove configuration files when the ''--purge'' flag is used. Make sure you have backups of your configuration files.

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 package2

'''Gentoo'''

The correct way to remove packages on gentoo.
emerge --depclean package1 package2

In case you know what you're doing, you may skip dependency checks and potentiality leave your system in broken state.
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 gigabytes of storage space.

'''Alpine'''

Alpine will clean up packages automatically.

'''Gentoo'''

The following command will leave ''/var/cache/distfiles/'' folder intact, while deleting all children.

find /var/cache/distfiles/ -mindepth 1 -delete

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

Recent versions of portage include library tracking and preservation with the preserved-libs feature. Portage will notify you to run {{Cmd|emerge @preserved-rebuild}} to help rebuild binaries that might otherwise become broken.

'''Debian'''

Reverse dependencies are taken care of by dpkg.

= Runlevel & Initscripts =
Runlevels work pretty conventionally on Debian (see details: [http://archive.fo/ZdZIz systemd]{{dead link}}). On Alpine and Gentoo, they are a bit different.

== Directories and files ==
{{Obsolete|Debian now uses systemd.}}

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

'''Alpine'''

In Alpine, runlevels work like they do in Gentoo:

* /etc/runlevels/boot
* /etc/runlevels/default
* /etc/runlevels/sysinit
* /etc/runlevels/nonetwork
* /etc/runlevels/shutdown

== 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-update add sshd default
To remove sshd from all runlevels do:
rc-update del 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 [http://gentoo-wiki.com/Rc-update 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/portage/make.conf and use flags ==
While in Gentoo there's a large number of configuration files which 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 it. In Gentoo, the file /etc/portage/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"'''

== Architectures and repositories ==
'''Gentoo'''

Also in /etc/portage/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/portage/make.conf. Rather configure this per-package in /etc/portage/package.accept_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/Rosetta Stone =

This chart shows how some standard things are done in Alpine compared to other distributions.

{| cellpadding="5" border="1" class="wikitable"
|-
! Action
! Alpine ([https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management apk])
! Arch Linux ([https://wiki.archlinux.org/index.php/Pacman pacman])
! Gentoo ([https://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1 emerge])
! Debian/Ubuntu ([https://wiki.debian.org/AptCLI apt])
! Fedora/RHEL/SL/CentOS ([http://yum.baseurl.org/wiki/YumCommands yum])
! VoidLinux ([https://docs.voidlinux.org/xbps/index.html?highlight=xb#xbps-package-manager XBPS])
|-
| Update package database
| {{Cmd| apk update}}
| {{Cmd| pacman -Sy}}
| {{Cmd| emerge --sync}}
| {{Cmd| apt update}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -S}}
|-
| Showing available updates
| {{Cmd| apk version -l '<'}}
| {{Cmd| pacman -Qu}}
| {{Cmd| emerge --deep --update --pretend @world}}
| {{Cmd| apt upgrade --simulate}}
| {{Cmd| yum list updates}}
| {{Cmd| xbps-install -n -u}}
|-
| Installing packages
| {{Cmd| apk add [package name]}}
| {{Cmd| pacman -S [package name]}}
| {{Cmd| emerge [package name]}}
| {{Cmd| apt install [package name]}}
| {{Cmd| yum install [package name]}}
| {{Cmd| xbps-install [package name]}}
|-
| Update all installed packages
| {{Cmd| apk upgrade -U -a}}
| {{Cmd| pacman -Su}}
| {{Cmd| emerge --update --deep @world}}
| {{Cmd| apt upgrade}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -u}}
|-
| Searching package database
| {{Cmd| apk search -v '[string]*'}}
| {{Cmd| pacman -Ss [string]}}
| {{Cmd| emerge --search [string]}}
| {{Cmd| apt search [string]}}
| {{Cmd| yum search [string]}}
| {{Cmd| xbps-query -Rs [string]}}
|-
| Removing packages
| {{Cmd| apk del [package name]}}
| {{Cmd| pacman -R [package name]}}
| {{Cmd| emerge --depclean [package name]}}
| {{Cmd| apt remove [package name]}}
| {{Cmd| yum remove [package name]}}
| {{Cmd| xbps-remove [package name]}}
|}

[[Category:Package Manager]]

Comparison with other distros

2022-08-15T18:23:36Z

Winny: /* Reverse dependencies */ you never need revdep-rebuild anymore

Even if Alpine is designed to run from RAM, it has some similarities in package management with other distributions. This page outlines those similarities and differences, to help new users use Alpine and understand the differences between Alpine and other distributions.

{{Note|The page was originally copied from: [https://web.archive.org/web/20070911124125/http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian]}}

 

= Package management =
Where Gentoo has portage and emerge; Debian has, among others, apt; Alpine uses apk-tools. This section compares how apk-tools is used, in comparison to apt and emerge.

== Updating package database ==
Gentoo will update the build-from-source scripts and the updating of the database takes much more time than updating the database for Debian or Alpine.

'''Alpine'''
apk update

'''Debian'''
apt update

'''Gentoo'''
emerge --sync

== Showing available updates ==
Show which packages have an update available:

'''Alpine'''
apk version -v
or:
apk version -v -l '<'

'''Gentoo'''
emerge --deep --update --pretend @world

'''Debian'''
apt upgrade --simulate

== Updating a particular package ==
'''Alpine'''
apk add -u package1 package2
or
apk upgrade package1 package2
'''Debian'''
apt install package1 package2
'''Gentoo'''
emerge --update package1 package2

== Installing packages ==
'''Alpine'''
apk add package1 package2

For source compile, see the [[Aports tree]] and the [[abuild]] tool.

'''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 the "Architectures and repositories" section below.

== Reinstalling particular packages ==
'''Alpine'''
apk del package1 package2 && apk add package1 package2
or:
apk fix 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 the package database ==
'''Alpine'''

Alpine will only search package names.
apk search searchword

'''Gentoo'''

To search the package names and descriptions:
emerge --searchdesc searchword
'''Note:''' On Gentoo, it's actually much better to install and use the eix package to do a search. You use them like this:
eix 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 del package1 package2
''apk del'' will remove configuration files when the ''--purge'' flag is used. Make sure you have backups of your configuration files.

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 package2

'''Gentoo'''

The correct way to remove packages on gentoo.
emerge --depclean package1 package2

In case you know what you're doing, you may skip dependency checks and potentiality leave your system in broken state.
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 gigabytes of storage space.

'''Alpine'''

Alpine will clean up packages automatically.

'''Gentoo'''

The following command will leave ''/var/cache/distfiles/'' folder intact, while deleting all children.

find /var/cache/distfiles/ -mindepth 1 -delete

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

Recent versions of portage include library tracking and preservation with the preserved-libs feature. Portage will notify you to run {{Cmd|emerge @preserved-rebuild}} to help rebuild binaries that might otherwise become broken.

'''Debian'''

Reverse dependencies are taken care of by dpkg.

= Runlevel & Initscripts =
Runlevels work pretty conventionally on Debian (see details: [http://archive.fo/ZdZIz systemd]{{dead link}}). 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

'''Alpine'''

In Alpine, runlevels work like they do in Gentoo:

* /etc/runlevels/boot
* /etc/runlevels/default
* /etc/runlevels/sysinit
* /etc/runlevels/nonetwork
* /etc/runlevels/shutdown

== 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-update add sshd default
To remove sshd from all runlevels do:
rc-update del 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 [http://gentoo-wiki.com/Rc-update 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/portage/make.conf and use flags ==
While in Gentoo there's a large number of configuration files which 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 it. In Gentoo, the file /etc/portage/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"'''

== Architectures and repositories ==
'''Gentoo'''

Also in /etc/portage/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/portage/make.conf. Rather configure this per-package in /etc/portage/package.accept_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/Rosetta Stone =

This chart shows how some standard things are done in Alpine compared to other distributions.

{| cellpadding="5" border="1" class="wikitable"
|-
! Action
! Alpine ([https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management apk])
! Arch Linux ([https://wiki.archlinux.org/index.php/Pacman pacman])
! Gentoo ([https://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1 emerge])
! Debian/Ubuntu ([https://wiki.debian.org/AptCLI apt])
! Fedora/RHEL/SL/CentOS ([http://yum.baseurl.org/wiki/YumCommands yum])
! VoidLinux ([https://docs.voidlinux.org/xbps/index.html?highlight=xb#xbps-package-manager XBPS])
|-
| Update package database
| {{Cmd| apk update}}
| {{Cmd| pacman -Sy}}
| {{Cmd| emerge --sync}}
| {{Cmd| apt update}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -S}}
|-
| Showing available updates
| {{Cmd| apk version -l '<'}}
| {{Cmd| pacman -Qu}}
| {{Cmd| emerge --deep --update --pretend @world}}
| {{Cmd| apt upgrade --simulate}}
| {{Cmd| yum list updates}}
| {{Cmd| xbps-install -n -u}}
|-
| Installing packages
| {{Cmd| apk add [package name]}}
| {{Cmd| pacman -S [package name]}}
| {{Cmd| emerge [package name]}}
| {{Cmd| apt install [package name]}}
| {{Cmd| yum install [package name]}}
| {{Cmd| xbps-install [package name]}}
|-
| Update all installed packages
| {{Cmd| apk upgrade -U -a}}
| {{Cmd| pacman -Su}}
| {{Cmd| emerge --update --deep @world}}
| {{Cmd| apt upgrade}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -u}}
|-
| Searching package database
| {{Cmd| apk search -v '[string]*'}}
| {{Cmd| pacman -Ss [string]}}
| {{Cmd| emerge --search [string]}}
| {{Cmd| apt search [string]}}
| {{Cmd| yum search [string]}}
| {{Cmd| xbps-query -Rs [string]}}
|-
| Removing packages
| {{Cmd| apk del [package name]}}
| {{Cmd| pacman -R [package name]}}
| {{Cmd| emerge --depclean [package name]}}
| {{Cmd| apt remove [package name]}}
| {{Cmd| yum remove [package name]}}
| {{Cmd| xbps-remove [package name]}}
|}

[[Category:Package Manager]]

Comparison with other distros

2022-08-15T18:21:25Z

Winny: /* Cleaning up downloaded packages */ less foot gun

Even if Alpine is designed to run from RAM, it has some similarities in package management with other distributions. This page outlines those similarities and differences, to help new users use Alpine and understand the differences between Alpine and other distributions.

{{Note|The page was originally copied from: [https://web.archive.org/web/20070911124125/http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian]}}

 

= Package management =
Where Gentoo has portage and emerge; Debian has, among others, apt; Alpine uses apk-tools. This section compares how apk-tools is used, in comparison to apt and emerge.

== Updating package database ==
Gentoo will update the build-from-source scripts and the updating of the database takes much more time than updating the database for Debian or Alpine.

'''Alpine'''
apk update

'''Debian'''
apt update

'''Gentoo'''
emerge --sync

== Showing available updates ==
Show which packages have an update available:

'''Alpine'''
apk version -v
or:
apk version -v -l '<'

'''Gentoo'''
emerge --deep --update --pretend @world

'''Debian'''
apt upgrade --simulate

== Updating a particular package ==
'''Alpine'''
apk add -u package1 package2
or
apk upgrade package1 package2
'''Debian'''
apt install package1 package2
'''Gentoo'''
emerge --update package1 package2

== Installing packages ==
'''Alpine'''
apk add package1 package2

For source compile, see the [[Aports tree]] and the [[abuild]] tool.

'''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 the "Architectures and repositories" section below.

== Reinstalling particular packages ==
'''Alpine'''
apk del package1 package2 && apk add package1 package2
or:
apk fix 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 the package database ==
'''Alpine'''

Alpine will only search package names.
apk search searchword

'''Gentoo'''

To search the package names and descriptions:
emerge --searchdesc searchword
'''Note:''' On Gentoo, it's actually much better to install and use the eix package to do a search. You use them like this:
eix 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 del package1 package2
''apk del'' will remove configuration files when the ''--purge'' flag is used. Make sure you have backups of your configuration files.

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 package2

'''Gentoo'''

The correct way to remove packages on gentoo.
emerge --depclean package1 package2

In case you know what you're doing, you may skip dependency checks and potentiality leave your system in broken state.
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 gigabytes of storage space.

'''Alpine'''

Alpine will clean up packages automatically.

'''Gentoo'''

The following command will leave ''/var/cache/distfiles/'' folder intact, while deleting all children.

find /var/cache/distfiles/ -mindepth 1 -delete

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.
If you use the unsafe --unmerge argument, 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

Recent versions of portage include library tracking and preservation with the preserved-libs feature. Portage will notify you to run {{Cmd| emerge @preserved-rebuild}} to help rebuild binaries that might otherwise become broken.

'''Debian'''

Reverse dependencies are taken care of by dpkg.

= Runlevel & Initscripts =
Runlevels work pretty conventionally on Debian (see details: [http://archive.fo/ZdZIz systemd]{{dead link}}). 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

'''Alpine'''

In Alpine, runlevels work like they do in Gentoo:

* /etc/runlevels/boot
* /etc/runlevels/default
* /etc/runlevels/sysinit
* /etc/runlevels/nonetwork
* /etc/runlevels/shutdown

== 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-update add sshd default
To remove sshd from all runlevels do:
rc-update del 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 [http://gentoo-wiki.com/Rc-update 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/portage/make.conf and use flags ==
While in Gentoo there's a large number of configuration files which 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 it. In Gentoo, the file /etc/portage/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"'''

== Architectures and repositories ==
'''Gentoo'''

Also in /etc/portage/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/portage/make.conf. Rather configure this per-package in /etc/portage/package.accept_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/Rosetta Stone =

This chart shows how some standard things are done in Alpine compared to other distributions.

{| cellpadding="5" border="1" class="wikitable"
|-
! Action
! Alpine ([https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management apk])
! Arch Linux ([https://wiki.archlinux.org/index.php/Pacman pacman])
! Gentoo ([https://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1 emerge])
! Debian/Ubuntu ([https://wiki.debian.org/AptCLI apt])
! Fedora/RHEL/SL/CentOS ([http://yum.baseurl.org/wiki/YumCommands yum])
! VoidLinux ([https://docs.voidlinux.org/xbps/index.html?highlight=xb#xbps-package-manager XBPS])
|-
| Update package database
| {{Cmd| apk update}}
| {{Cmd| pacman -Sy}}
| {{Cmd| emerge --sync}}
| {{Cmd| apt update}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -S}}
|-
| Showing available updates
| {{Cmd| apk version -l '<'}}
| {{Cmd| pacman -Qu}}
| {{Cmd| emerge --deep --update --pretend @world}}
| {{Cmd| apt upgrade --simulate}}
| {{Cmd| yum list updates}}
| {{Cmd| xbps-install -n -u}}
|-
| Installing packages
| {{Cmd| apk add [package name]}}
| {{Cmd| pacman -S [package name]}}
| {{Cmd| emerge [package name]}}
| {{Cmd| apt install [package name]}}
| {{Cmd| yum install [package name]}}
| {{Cmd| xbps-install [package name]}}
|-
| Update all installed packages
| {{Cmd| apk upgrade -U -a}}
| {{Cmd| pacman -Su}}
| {{Cmd| emerge --update --deep @world}}
| {{Cmd| apt upgrade}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -u}}
|-
| Searching package database
| {{Cmd| apk search -v '[string]*'}}
| {{Cmd| pacman -Ss [string]}}
| {{Cmd| emerge --search [string]}}
| {{Cmd| apt search [string]}}
| {{Cmd| yum search [string]}}
| {{Cmd| xbps-query -Rs [string]}}
|-
| Removing packages
| {{Cmd| apk del [package name]}}
| {{Cmd| pacman -R [package name]}}
| {{Cmd| emerge --depclean [package name]}}
| {{Cmd| apt remove [package name]}}
| {{Cmd| yum remove [package name]}}
| {{Cmd| xbps-remove [package name]}}
|}

[[Category:Package Manager]]

Comparison with other distros

2022-08-15T18:16:49Z

Winny: /* Removing packages */ clarify you almost always want --depclean

Even if Alpine is designed to run from RAM, it has some similarities in package management with other distributions. This page outlines those similarities and differences, to help new users use Alpine and understand the differences between Alpine and other distributions.

{{Note|The page was originally copied from: [https://web.archive.org/web/20070911124125/http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian]}}

 

= Package management =
Where Gentoo has portage and emerge; Debian has, among others, apt; Alpine uses apk-tools. This section compares how apk-tools is used, in comparison to apt and emerge.

== Updating package database ==
Gentoo will update the build-from-source scripts and the updating of the database takes much more time than updating the database for Debian or Alpine.

'''Alpine'''
apk update

'''Debian'''
apt update

'''Gentoo'''
emerge --sync

== Showing available updates ==
Show which packages have an update available:

'''Alpine'''
apk version -v
or:
apk version -v -l '<'

'''Gentoo'''
emerge --deep --update --pretend @world

'''Debian'''
apt upgrade --simulate

== Updating a particular package ==
'''Alpine'''
apk add -u package1 package2
or
apk upgrade package1 package2
'''Debian'''
apt install package1 package2
'''Gentoo'''
emerge --update package1 package2

== Installing packages ==
'''Alpine'''
apk add package1 package2

For source compile, see the [[Aports tree]] and the [[abuild]] tool.

'''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 the "Architectures and repositories" section below.

== Reinstalling particular packages ==
'''Alpine'''
apk del package1 package2 && apk add package1 package2
or:
apk fix 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 the package database ==
'''Alpine'''

Alpine will only search package names.
apk search searchword

'''Gentoo'''

To search the package names and descriptions:
emerge --searchdesc searchword
'''Note:''' On Gentoo, it's actually much better to install and use the eix package to do a search. You use them like this:
eix 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 del package1 package2
''apk del'' will remove configuration files when the ''--purge'' flag is used. Make sure you have backups of your configuration files.

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 package2

'''Gentoo'''

The correct way to remove packages on gentoo.
emerge --depclean package1 package2

In case you know what you're doing, you may skip dependency checks and potentiality leave your system in broken state.
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 gigabytes of storage space.

'''Alpine'''

Alpine will clean up packages automatically.

'''Gentoo'''
rm -rf /var/cache/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.
If you use the unsafe --unmerge argument, 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

Recent versions of portage include library tracking and preservation with the preserved-libs feature. Portage will notify you to run {{Cmd| emerge @preserved-rebuild}} to help rebuild binaries that might otherwise become broken.

'''Debian'''

Reverse dependencies are taken care of by dpkg.

= Runlevel & Initscripts =
Runlevels work pretty conventionally on Debian (see details: [http://archive.fo/ZdZIz systemd]{{dead link}}). 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

'''Alpine'''

In Alpine, runlevels work like they do in Gentoo:

* /etc/runlevels/boot
* /etc/runlevels/default
* /etc/runlevels/sysinit
* /etc/runlevels/nonetwork
* /etc/runlevels/shutdown

== 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-update add sshd default
To remove sshd from all runlevels do:
rc-update del 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 [http://gentoo-wiki.com/Rc-update 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/portage/make.conf and use flags ==
While in Gentoo there's a large number of configuration files which 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 it. In Gentoo, the file /etc/portage/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"'''

== Architectures and repositories ==
'''Gentoo'''

Also in /etc/portage/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/portage/make.conf. Rather configure this per-package in /etc/portage/package.accept_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/Rosetta Stone =

This chart shows how some standard things are done in Alpine compared to other distributions.

{| cellpadding="5" border="1" class="wikitable"
|-
! Action
! Alpine ([https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management apk])
! Arch Linux ([https://wiki.archlinux.org/index.php/Pacman pacman])
! Gentoo ([https://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1 emerge])
! Debian/Ubuntu ([https://wiki.debian.org/AptCLI apt])
! Fedora/RHEL/SL/CentOS ([http://yum.baseurl.org/wiki/YumCommands yum])
! VoidLinux ([https://docs.voidlinux.org/xbps/index.html?highlight=xb#xbps-package-manager XBPS])
|-
| Update package database
| {{Cmd| apk update}}
| {{Cmd| pacman -Sy}}
| {{Cmd| emerge --sync}}
| {{Cmd| apt update}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -S}}
|-
| Showing available updates
| {{Cmd| apk version -l '<'}}
| {{Cmd| pacman -Qu}}
| {{Cmd| emerge --deep --update --pretend @world}}
| {{Cmd| apt upgrade --simulate}}
| {{Cmd| yum list updates}}
| {{Cmd| xbps-install -n -u}}
|-
| Installing packages
| {{Cmd| apk add [package name]}}
| {{Cmd| pacman -S [package name]}}
| {{Cmd| emerge [package name]}}
| {{Cmd| apt install [package name]}}
| {{Cmd| yum install [package name]}}
| {{Cmd| xbps-install [package name]}}
|-
| Update all installed packages
| {{Cmd| apk upgrade -U -a}}
| {{Cmd| pacman -Su}}
| {{Cmd| emerge --update --deep @world}}
| {{Cmd| apt upgrade}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -u}}
|-
| Searching package database
| {{Cmd| apk search -v '[string]*'}}
| {{Cmd| pacman -Ss [string]}}
| {{Cmd| emerge --search [string]}}
| {{Cmd| apt search [string]}}
| {{Cmd| yum search [string]}}
| {{Cmd| xbps-query -Rs [string]}}
|-
| Removing packages
| {{Cmd| apk del [package name]}}
| {{Cmd| pacman -R [package name]}}
| {{Cmd| emerge --depclean [package name]}}
| {{Cmd| apt remove [package name]}}
| {{Cmd| yum remove [package name]}}
| {{Cmd| xbps-remove [package name]}}
|}

[[Category:Package Manager]]

Comparison with other distros

2022-08-15T18:13:02Z

Winny: /* Searching the package database */ esearch... nobody uses this

Even if Alpine is designed to run from RAM, it has some similarities in package management with other distributions. This page outlines those similarities and differences, to help new users use Alpine and understand the differences between Alpine and other distributions.

{{Note|The page was originally copied from: [https://web.archive.org/web/20070911124125/http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian]}}

 

= Package management =
Where Gentoo has portage and emerge; Debian has, among others, apt; Alpine uses apk-tools. This section compares how apk-tools is used, in comparison to apt and emerge.

== Updating package database ==
Gentoo will update the build-from-source scripts and the updating of the database takes much more time than updating the database for Debian or Alpine.

'''Alpine'''
apk update

'''Debian'''
apt update

'''Gentoo'''
emerge --sync

== Showing available updates ==
Show which packages have an update available:

'''Alpine'''
apk version -v
or:
apk version -v -l '<'

'''Gentoo'''
emerge --deep --update --pretend @world

'''Debian'''
apt upgrade --simulate

== Updating a particular package ==
'''Alpine'''
apk add -u package1 package2
or
apk upgrade package1 package2
'''Debian'''
apt install package1 package2
'''Gentoo'''
emerge --update package1 package2

== Installing packages ==
'''Alpine'''
apk add package1 package2

For source compile, see the [[Aports tree]] and the [[abuild]] tool.

'''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 the "Architectures and repositories" section below.

== Reinstalling particular packages ==
'''Alpine'''
apk del package1 package2 && apk add package1 package2
or:
apk fix 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 the package database ==
'''Alpine'''

Alpine will only search package names.
apk search searchword

'''Gentoo'''

To search the package names and descriptions:
emerge --searchdesc searchword
'''Note:''' On Gentoo, it's actually much better to install and use the eix package to do a search. You use them like this:
eix 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 del package1 package2
apk del will remove configuration files when the --purge flag is used. 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 package2

'''Gentoo'''
emerge --unmerge package1 package2 (Note: this is unsafe as it does not check dependencies)
emerge --depclean package1 package2 (This will check dependencies)

'''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 gigabytes of storage space.

'''Alpine'''

Alpine will clean up packages automatically.

'''Gentoo'''
rm -rf /var/cache/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.
If you use the unsafe --unmerge argument, 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

Recent versions of portage include library tracking and preservation with the preserved-libs feature. Portage will notify you to run {{Cmd| emerge @preserved-rebuild}} to help rebuild binaries that might otherwise become broken.

'''Debian'''

Reverse dependencies are taken care of by dpkg.

= Runlevel & Initscripts =
Runlevels work pretty conventionally on Debian (see details: [http://archive.fo/ZdZIz systemd]{{dead link}}). 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

'''Alpine'''

In Alpine, runlevels work like they do in Gentoo:

* /etc/runlevels/boot
* /etc/runlevels/default
* /etc/runlevels/sysinit
* /etc/runlevels/nonetwork
* /etc/runlevels/shutdown

== 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-update add sshd default
To remove sshd from all runlevels do:
rc-update del 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 [http://gentoo-wiki.com/Rc-update 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/portage/make.conf and use flags ==
While in Gentoo there's a large number of configuration files which 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 it. In Gentoo, the file /etc/portage/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"'''

== Architectures and repositories ==
'''Gentoo'''

Also in /etc/portage/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/portage/make.conf. Rather configure this per-package in /etc/portage/package.accept_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/Rosetta Stone =

This chart shows how some standard things are done in Alpine compared to other distributions.

{| cellpadding="5" border="1" class="wikitable"
|-
! Action
! Alpine ([https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management apk])
! Arch Linux ([https://wiki.archlinux.org/index.php/Pacman pacman])
! Gentoo ([https://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1 emerge])
! Debian/Ubuntu ([https://wiki.debian.org/AptCLI apt])
! Fedora/RHEL/SL/CentOS ([http://yum.baseurl.org/wiki/YumCommands yum])
! VoidLinux ([https://docs.voidlinux.org/xbps/index.html?highlight=xb#xbps-package-manager XBPS])
|-
| Update package database
| {{Cmd| apk update}}
| {{Cmd| pacman -Sy}}
| {{Cmd| emerge --sync}}
| {{Cmd| apt update}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -S}}
|-
| Showing available updates
| {{Cmd| apk version -l '<'}}
| {{Cmd| pacman -Qu}}
| {{Cmd| emerge --deep --update --pretend @world}}
| {{Cmd| apt upgrade --simulate}}
| {{Cmd| yum list updates}}
| {{Cmd| xbps-install -n -u}}
|-
| Installing packages
| {{Cmd| apk add [package name]}}
| {{Cmd| pacman -S [package name]}}
| {{Cmd| emerge [package name]}}
| {{Cmd| apt install [package name]}}
| {{Cmd| yum install [package name]}}
| {{Cmd| xbps-install [package name]}}
|-
| Update all installed packages
| {{Cmd| apk upgrade -U -a}}
| {{Cmd| pacman -Su}}
| {{Cmd| emerge --update --deep @world}}
| {{Cmd| apt upgrade}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -u}}
|-
| Searching package database
| {{Cmd| apk search -v '[string]*'}}
| {{Cmd| pacman -Ss [string]}}
| {{Cmd| emerge --search [string]}}
| {{Cmd| apt search [string]}}
| {{Cmd| yum search [string]}}
| {{Cmd| xbps-query -Rs [string]}}
|-
| Removing packages
| {{Cmd| apk del [package name]}}
| {{Cmd| pacman -R [package name]}}
| {{Cmd| emerge --depclean [package name]}}
| {{Cmd| apt remove [package name]}}
| {{Cmd| yum remove [package name]}}
| {{Cmd| xbps-remove [package name]}}
|}

[[Category:Package Manager]]

Comparison with other distros

2022-08-15T18:11:57Z

Winny: /* Updating package database */ fix gentoo sync command

Even if Alpine is designed to run from RAM, it has some similarities in package management with other distributions. This page outlines those similarities and differences, to help new users use Alpine and understand the differences between Alpine and other distributions.

{{Note|The page was originally copied from: [https://web.archive.org/web/20070911124125/http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian]}}

 

= Package management =
Where Gentoo has portage and emerge; Debian has, among others, apt; Alpine uses apk-tools. This section compares how apk-tools is used, in comparison to apt and emerge.

== Updating package database ==
Gentoo will update the build-from-source scripts and the updating of the database takes much more time than updating the database for Debian or Alpine.

'''Alpine'''
apk update

'''Debian'''
apt update

'''Gentoo'''
emerge --sync

== Showing available updates ==
Show which packages have an update available:

'''Alpine'''
apk version -v
or:
apk version -v -l '<'

'''Gentoo'''
emerge --deep --update --pretend @world

'''Debian'''
apt upgrade --simulate

== Updating a particular package ==
'''Alpine'''
apk add -u package1 package2
or
apk upgrade package1 package2
'''Debian'''
apt install package1 package2
'''Gentoo'''
emerge --update package1 package2

== Installing packages ==
'''Alpine'''
apk add package1 package2

For source compile, see the [[Aports tree]] and the [[abuild]] tool.

'''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 the "Architectures and repositories" section below.

== Reinstalling particular packages ==
'''Alpine'''
apk del package1 package2 && apk add package1 package2
or:
apk fix 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 the package database ==
'''Alpine'''

Alpine will only search package names.
apk search 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 del package1 package2
apk del will remove configuration files when the --purge flag is used. 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 package2

'''Gentoo'''
emerge --unmerge package1 package2 (Note: this is unsafe as it does not check dependencies)
emerge --depclean package1 package2 (This will check dependencies)

'''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 gigabytes of storage space.

'''Alpine'''

Alpine will clean up packages automatically.

'''Gentoo'''
rm -rf /var/cache/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.
If you use the unsafe --unmerge argument, 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

Recent versions of portage include library tracking and preservation with the preserved-libs feature. Portage will notify you to run {{Cmd| emerge @preserved-rebuild}} to help rebuild binaries that might otherwise become broken.

'''Debian'''

Reverse dependencies are taken care of by dpkg.

= Runlevel & Initscripts =
Runlevels work pretty conventionally on Debian (see details: [http://archive.fo/ZdZIz systemd]{{dead link}}). 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

'''Alpine'''

In Alpine, runlevels work like they do in Gentoo:

* /etc/runlevels/boot
* /etc/runlevels/default
* /etc/runlevels/sysinit
* /etc/runlevels/nonetwork
* /etc/runlevels/shutdown

== 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-update add sshd default
To remove sshd from all runlevels do:
rc-update del 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 [http://gentoo-wiki.com/Rc-update 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/portage/make.conf and use flags ==
While in Gentoo there's a large number of configuration files which 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 it. In Gentoo, the file /etc/portage/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"'''

== Architectures and repositories ==
'''Gentoo'''

Also in /etc/portage/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/portage/make.conf. Rather configure this per-package in /etc/portage/package.accept_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/Rosetta Stone =

This chart shows how some standard things are done in Alpine compared to other distributions.

{| cellpadding="5" border="1" class="wikitable"
|-
! Action
! Alpine ([https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management apk])
! Arch Linux ([https://wiki.archlinux.org/index.php/Pacman pacman])
! Gentoo ([https://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1 emerge])
! Debian/Ubuntu ([https://wiki.debian.org/AptCLI apt])
! Fedora/RHEL/SL/CentOS ([http://yum.baseurl.org/wiki/YumCommands yum])
! VoidLinux ([https://docs.voidlinux.org/xbps/index.html?highlight=xb#xbps-package-manager XBPS])
|-
| Update package database
| {{Cmd| apk update}}
| {{Cmd| pacman -Sy}}
| {{Cmd| emerge --sync}}
| {{Cmd| apt update}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -S}}
|-
| Showing available updates
| {{Cmd| apk version -l '<'}}
| {{Cmd| pacman -Qu}}
| {{Cmd| emerge --deep --update --pretend @world}}
| {{Cmd| apt upgrade --simulate}}
| {{Cmd| yum list updates}}
| {{Cmd| xbps-install -n -u}}
|-
| Installing packages
| {{Cmd| apk add [package name]}}
| {{Cmd| pacman -S [package name]}}
| {{Cmd| emerge [package name]}}
| {{Cmd| apt install [package name]}}
| {{Cmd| yum install [package name]}}
| {{Cmd| xbps-install [package name]}}
|-
| Update all installed packages
| {{Cmd| apk upgrade -U -a}}
| {{Cmd| pacman -Su}}
| {{Cmd| emerge --update --deep @world}}
| {{Cmd| apt upgrade}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -u}}
|-
| Searching package database
| {{Cmd| apk search -v '[string]*'}}
| {{Cmd| pacman -Ss [string]}}
| {{Cmd| emerge --search [string]}}
| {{Cmd| apt search [string]}}
| {{Cmd| yum search [string]}}
| {{Cmd| xbps-query -Rs [string]}}
|-
| Removing packages
| {{Cmd| apk del [package name]}}
| {{Cmd| pacman -R [package name]}}
| {{Cmd| emerge --depclean [package name]}}
| {{Cmd| apt remove [package name]}}
| {{Cmd| yum remove [package name]}}
| {{Cmd| xbps-remove [package name]}}
|}

[[Category:Package Manager]]

Comparison with other distros

2022-08-15T18:11:32Z

Winny: /* Package management */ remove misleading note about binary/src distros. Gentoo is both. Alpine is both. It's just a matter how you install packages on a target machine. Do you build on the same machine or distribute binpkgs to another machine?

Even if Alpine is designed to run from RAM, it has some similarities in package management with other distributions. This page outlines those similarities and differences, to help new users use Alpine and understand the differences between Alpine and other distributions.

{{Note|The page was originally copied from: [https://web.archive.org/web/20070911124125/http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian]}}

 

= Package management =
Where Gentoo has portage and emerge; Debian has, among others, apt; Alpine uses apk-tools. This section compares how apk-tools is used, in comparison to apt and emerge.

== Updating package database ==
Gentoo will update the build-from-source scripts and the updating of the database takes much more time than updating the database for Debian or Alpine.

'''Alpine'''
apk update

'''Debian'''
apt update

'''Gentoo'''
emaint sync -a

== Showing available updates ==
Show which packages have an update available:

'''Alpine'''
apk version -v
or:
apk version -v -l '<'

'''Gentoo'''
emerge --deep --update --pretend @world

'''Debian'''
apt upgrade --simulate

== Updating a particular package ==
'''Alpine'''
apk add -u package1 package2
or
apk upgrade package1 package2
'''Debian'''
apt install package1 package2
'''Gentoo'''
emerge --update package1 package2

== Installing packages ==
'''Alpine'''
apk add package1 package2

For source compile, see the [[Aports tree]] and the [[abuild]] tool.

'''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 the "Architectures and repositories" section below.

== Reinstalling particular packages ==
'''Alpine'''
apk del package1 package2 && apk add package1 package2
or:
apk fix 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 the package database ==
'''Alpine'''

Alpine will only search package names.
apk search 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 del package1 package2
apk del will remove configuration files when the --purge flag is used. 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 package2

'''Gentoo'''
emerge --unmerge package1 package2 (Note: this is unsafe as it does not check dependencies)
emerge --depclean package1 package2 (This will check dependencies)

'''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 gigabytes of storage space.

'''Alpine'''

Alpine will clean up packages automatically.

'''Gentoo'''
rm -rf /var/cache/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.
If you use the unsafe --unmerge argument, 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

Recent versions of portage include library tracking and preservation with the preserved-libs feature. Portage will notify you to run {{Cmd| emerge @preserved-rebuild}} to help rebuild binaries that might otherwise become broken.

'''Debian'''

Reverse dependencies are taken care of by dpkg.

= Runlevel & Initscripts =
Runlevels work pretty conventionally on Debian (see details: [http://archive.fo/ZdZIz systemd]{{dead link}}). 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

'''Alpine'''

In Alpine, runlevels work like they do in Gentoo:

* /etc/runlevels/boot
* /etc/runlevels/default
* /etc/runlevels/sysinit
* /etc/runlevels/nonetwork
* /etc/runlevels/shutdown

== 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-update add sshd default
To remove sshd from all runlevels do:
rc-update del 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 [http://gentoo-wiki.com/Rc-update 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/portage/make.conf and use flags ==
While in Gentoo there's a large number of configuration files which 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 it. In Gentoo, the file /etc/portage/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"'''

== Architectures and repositories ==
'''Gentoo'''

Also in /etc/portage/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/portage/make.conf. Rather configure this per-package in /etc/portage/package.accept_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/Rosetta Stone =

This chart shows how some standard things are done in Alpine compared to other distributions.

{| cellpadding="5" border="1" class="wikitable"
|-
! Action
! Alpine ([https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management apk])
! Arch Linux ([https://wiki.archlinux.org/index.php/Pacman pacman])
! Gentoo ([https://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1 emerge])
! Debian/Ubuntu ([https://wiki.debian.org/AptCLI apt])
! Fedora/RHEL/SL/CentOS ([http://yum.baseurl.org/wiki/YumCommands yum])
! VoidLinux ([https://docs.voidlinux.org/xbps/index.html?highlight=xb#xbps-package-manager XBPS])
|-
| Update package database
| {{Cmd| apk update}}
| {{Cmd| pacman -Sy}}
| {{Cmd| emerge --sync}}
| {{Cmd| apt update}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -S}}
|-
| Showing available updates
| {{Cmd| apk version -l '<'}}
| {{Cmd| pacman -Qu}}
| {{Cmd| emerge --deep --update --pretend @world}}
| {{Cmd| apt upgrade --simulate}}
| {{Cmd| yum list updates}}
| {{Cmd| xbps-install -n -u}}
|-
| Installing packages
| {{Cmd| apk add [package name]}}
| {{Cmd| pacman -S [package name]}}
| {{Cmd| emerge [package name]}}
| {{Cmd| apt install [package name]}}
| {{Cmd| yum install [package name]}}
| {{Cmd| xbps-install [package name]}}
|-
| Update all installed packages
| {{Cmd| apk upgrade -U -a}}
| {{Cmd| pacman -Su}}
| {{Cmd| emerge --update --deep @world}}
| {{Cmd| apt upgrade}}
| {{Cmd| yum update}}
| {{Cmd| xbps-install -u}}
|-
| Searching package database
| {{Cmd| apk search -v '[string]*'}}
| {{Cmd| pacman -Ss [string]}}
| {{Cmd| emerge --search [string]}}
| {{Cmd| apt search [string]}}
| {{Cmd| yum search [string]}}
| {{Cmd| xbps-query -Rs [string]}}
|-
| Removing packages
| {{Cmd| apk del [package name]}}
| {{Cmd| pacman -R [package name]}}
| {{Cmd| emerge --depclean [package name]}}
| {{Cmd| apt remove [package name]}}
| {{Cmd| yum remove [package name]}}
| {{Cmd| xbps-remove [package name]}}
|}

[[Category:Package Manager]]

Talk:Main Page

2022-08-15T17:53:54Z

Winny: note about the warning distraction

User:Winny

2022-08-15T17:50:51Z

Winny: user page

== 👋 Hi Alpine users ==

This is the homepage for Winny on the Alpinewiki. Here is my homepage: [https://winny.tech/ https://winny.tech/]

Bridge

2022-08-15T17:49:30Z

Winny: /* Bridging for a Xen dom0 */ formatting

[[Category:Networking]]
This document describes how to configure a [http://en.wikipedia.org/wiki/Bridging_%28networking%29 network bridge] interface in Alpine Linux.

== Using brctl ==

{{Obsolete|According to [https://wiki.linuxfoundation.org/networking/bridge upstream], ''bridge-utils'' is deprecated. Please use ''bridge'' instead.}}

Bridges are managed manually with the '''brctl''' command.
<pre>
Usage: brctl COMMAND [BRIDGE [INTERFACE]]

Manage ethernet bridges

Commands:
show Show a list of bridges
addbr BRIDGE Create BRIDGE
delbr BRIDGE Delete BRIDGE
addif BRIDGE IFACE Add IFACE to BRIDGE
delif BRIDGE IFACE Delete IFACE from BRIDGE
setageing BRIDGE TIME Set ageing time
setfd BRIDGE TIME Set bridge forward delay
sethello BRIDGE TIME Set hello time
setmaxage BRIDGE TIME Set max message age
setpathcost BRIDGE COST Set path cost
setportprio BRIDGE PRIO Set port priority
setbridgeprio BRIDGE PRIO Set bridge priority
stp BRIDGE [1|0] STP on/off
</pre>

To manually create bridge interface br0:
{{Cmd|brctl addbr br0}}

To add interface eth0 and eth1 to br0:
{{Cmd|brctl addif br0 eth0
brctl addif br0 eth1}}

Note: You need to set the link status to ''up'' on the added interfaces.
{{Cmd|ip link set dev eth0 up
ip link set dev eth1 up}}

[[Category:Networking]]

== Configuration file ==
Install the scripts that configure the bridge.
{{Cmd|apk add bridge}}

Bridging is then configured in ''/etc/network/interfaces'' with the ''bridge-ports'' keyword.
{{Warning|You normally don't assign ip addresses to the bridged interfaces (eth0 and eth1 in our example) but to the bridge itself (br0).}}

In this example the address 192.168.0.1/24 is used.

<pre>
auto br0
iface br0 inet static
bridge-ports eth0 eth1
bridge-stp 0
address 192.168.0.1
netmask 255.255.255.0
</pre>

You can set the various options with these keywords:
; bridge-ports
: Set bridge ports (ethX) or none for no physical interfaces
; bridge-aging
: Set ageing time
; bridge-fd
: Set bridge forward delay
; bridge-hello
: Set hello time
; bridge-maxage
: Set bridge max message age
; bridge-pathcost
: Set path cost
; bridge-portprio
: Set port priority
; bridge-bridgeprio
: Set bridge priority
; bridge-stp
: STP on/off

== Using pre-up/post-down ==
If you want be able to control the bridge interfaces individually, you need to use pre-up/post-down hooks.

Example ''/etc/network/interfaces'':

<pre>
auto br0
iface br0 inet static
pre-up brctl addbr br0
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
address 192.168.0.253
netmask 255.255.255.0
gateway 192.168.0.254
post-down brctl delbr br0

auto eth0
iface eth0 inet manual
up ip link set $IFACE up
up brctl addif br0 $IFACE
down brctl delif br0 $IFACE || true
down ip link set $IFACE down

auto eth1
iface eth1 inet manual
up ip link set $IFACE up
up brctl addif br0 $IFACE
down brctl delif br0 $IFACE || true
down ip link set $IFACE down
</pre>

That way, you create br0 with: ifup br0. You can add/remove
individual interfaces to the bridge with ifup eth0, ifdown eth0.

== Bridging for a Xen dom0 ==
Bridging in a dom0 is a bit specific as it consists in bridging a real interface (i.e. ethX) with a virtual interface (i.e. vifX.Y).
At bridge creation time, the virtual interface does not exist and will be added by the Xen toolstack when a domU is booting (see Xen documentation on how to link the virtual interface to the correct bridge).

'''Particulars:'''
* the bridge consists of a single physical interface
* the physical interface does not have an IP and is configured manually
* the bridge will have the IP address and will be auto, resulting in bringing up the physical interface

This translates to a sample config ''/etc/network/interfaces''

<pre>
auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
address 192.168.0.253
netmask 255.255.255.0
gateway 192.168.0.254
bridge_ports eth0
bridge_stp 0
</pre>

After the domU OS is started, the virtual interface wil be added and the working bridge can be checked with
<pre>
brctl show

ifconfig -a
</pre>

== Bridging for KVM ==

Example ''/etc/network/interfaces'':

{{Note|I personally remove the eth0 declaration without any issue.}}
<pre>
auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp 0
</pre>

=== Little script to allow dhcp over iptables ===
{{Note|I tried the Using pre-up/post-down as mentionned in #3, but it didn't work well for me }}
{{Note|Usually it will be in /etc/rc.local as mentioned [https://wiki.libvirt.org/page/Networking#Debian.2FUbuntu_Bridging here] }}

<pre>
# Run local.d scripts on boot.
rc-update add local

# Write the script.
cat >> /etc/local.d/iptables_dhcp_kvm.start << EOM
echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
exit 0
EOM

# local.d script must be executable.
chmod a+x /etc/local.d/iptables_dhcp_kvm.start
</pre>

== Bridging for QEMU ==

Replace ''/etc/network/interfaces'' with the following:

<pre>
auto lo
iface lo inet loopback

auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp 0
</pre>

To enable DHCP and get QEMU to use the bridge we've created above, run:

<pre>
# Install the bridge tools
apk add bridge

# Load kernel modules needed for KVM bridging.
printf 'tun\ntap\n' >> /etc/modules

# Allow Qemu to use our bridge.
echo 'allow br0' > /etc/qemu/bridge.conf

# Write some sysctl knobs to allow bridging to work.
printf '# Enable bridge forwarding.
net.ipv4.conf.br0_bc_forwarding=1
# Ignore iptables on bridge interfaces.
net.bridge.bridge-nf-call-iptables=0
' >> /etc/sysctl.d/bridging.conf

# Apply sysctl config edits.
sysctl -p
</pre>

After a ''reboot'', you can use the bridge like so (assuming you have a ''qcow2'' image named ''felix-pojtigners-theia.qcow2''):

<pre>
qemu-system-x86_64 -m 4096 -accel kvm -net nic -net bridge,br=br0 -boot d -drive format=qcow2,file=felix-pojtingers-theia.qcow2
</pre>

If you don't get a DHCP response for the guest machine (assuming you have a DHCP server running on the physical network that ''eth0'' is connected to), you can debug with ''tshark'':

<pre>
tshark -i eth0 -Y "bootp.option.type == 53"
</pre>

Bridge

2022-08-15T17:47:19Z

Winny: /* Using brctl */ mention that bridge-utils is deprecated

[[Category:Networking]]
This document describes how to configure a [http://en.wikipedia.org/wiki/Bridging_%28networking%29 network bridge] interface in Alpine Linux.

== Using brctl ==

{{Obsolete|According to [https://wiki.linuxfoundation.org/networking/bridge upstream], ''bridge-utils'' is deprecated. Please use ''bridge'' instead.}}

Bridges are managed manually with the '''brctl''' command.
<pre>
Usage: brctl COMMAND [BRIDGE [INTERFACE]]

Manage ethernet bridges

Commands:
show Show a list of bridges
addbr BRIDGE Create BRIDGE
delbr BRIDGE Delete BRIDGE
addif BRIDGE IFACE Add IFACE to BRIDGE
delif BRIDGE IFACE Delete IFACE from BRIDGE
setageing BRIDGE TIME Set ageing time
setfd BRIDGE TIME Set bridge forward delay
sethello BRIDGE TIME Set hello time
setmaxage BRIDGE TIME Set max message age
setpathcost BRIDGE COST Set path cost
setportprio BRIDGE PRIO Set port priority
setbridgeprio BRIDGE PRIO Set bridge priority
stp BRIDGE [1|0] STP on/off
</pre>

To manually create bridge interface br0:
{{Cmd|brctl addbr br0}}

To add interface eth0 and eth1 to br0:
{{Cmd|brctl addif br0 eth0
brctl addif br0 eth1}}

Note: You need to set the link status to ''up'' on the added interfaces.
{{Cmd|ip link set dev eth0 up
ip link set dev eth1 up}}

[[Category:Networking]]

== Configuration file ==
Install the scripts that configure the bridge.
{{Cmd|apk add bridge}}

Bridging is then configured in ''/etc/network/interfaces'' with the ''bridge-ports'' keyword.
{{Warning|You normally don't assign ip addresses to the bridged interfaces (eth0 and eth1 in our example) but to the bridge itself (br0).}}

In this example the address 192.168.0.1/24 is used.

<pre>
auto br0
iface br0 inet static
bridge-ports eth0 eth1
bridge-stp 0
address 192.168.0.1
netmask 255.255.255.0
</pre>

You can set the various options with these keywords:
; bridge-ports
: Set bridge ports (ethX) or none for no physical interfaces
; bridge-aging
: Set ageing time
; bridge-fd
: Set bridge forward delay
; bridge-hello
: Set hello time
; bridge-maxage
: Set bridge max message age
; bridge-pathcost
: Set path cost
; bridge-portprio
: Set port priority
; bridge-bridgeprio
: Set bridge priority
; bridge-stp
: STP on/off

== Using pre-up/post-down ==
If you want be able to control the bridge interfaces individually, you need to use pre-up/post-down hooks.

Example ''/etc/network/interfaces'':

<pre>
auto br0
iface br0 inet static
pre-up brctl addbr br0
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
address 192.168.0.253
netmask 255.255.255.0
gateway 192.168.0.254
post-down brctl delbr br0

auto eth0
iface eth0 inet manual
up ip link set $IFACE up
up brctl addif br0 $IFACE
down brctl delif br0 $IFACE || true
down ip link set $IFACE down

auto eth1
iface eth1 inet manual
up ip link set $IFACE up
up brctl addif br0 $IFACE
down brctl delif br0 $IFACE || true
down ip link set $IFACE down
</pre>

That way, you create br0 with: ifup br0. You can add/remove
individual interfaces to the bridge with ifup eth0, ifdown eth0.

== Bridging for a Xen dom0 ==
Bridging in a dom0 is a bit specific as it consists in bridging a real interface (i.e. ethX) with a virtual interface (i.e. vifX.Y).
At bridge creation time, the virtual interface does not exist and will be added by the Xen toolstack when a domU is booting (see Xen documentation on how to link the virtual interface to the correct bridge).

;Particulars :
- the bridge consists of a single physical interface 
- the physical interface does not have an IP and is configured manually 
- the bridge will have the IP address and will be auto, resulting in bringing up the physical interface 

This translates to a sample config :

Example ''/etc/network/interfaces'':

<pre>
auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
address 192.168.0.253
netmask 255.255.255.0
gateway 192.168.0.254
bridge_ports eth0
bridge_stp 0
</pre>

After the domU OS is started, the virtual interface wil be added and the working bridge can be checked with
<pre>
brctl show

ifconfig -a
</pre>

== Bridging for KVM ==

Example ''/etc/network/interfaces'':

{{Note|I personally remove the eth0 declaration without any issue.}}
<pre>
auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp 0
</pre>

=== Little script to allow dhcp over iptables ===
{{Note|I tried the Using pre-up/post-down as mentionned in #3, but it didn't work well for me }}
{{Note|Usually it will be in /etc/rc.local as mentioned [https://wiki.libvirt.org/page/Networking#Debian.2FUbuntu_Bridging here] }}

<pre>
# Run local.d scripts on boot.
rc-update add local

# Write the script.
cat >> /etc/local.d/iptables_dhcp_kvm.start << EOM
echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
exit 0
EOM

# local.d script must be executable.
chmod a+x /etc/local.d/iptables_dhcp_kvm.start
</pre>

== Bridging for QEMU ==

Replace ''/etc/network/interfaces'' with the following:

<pre>
auto lo
iface lo inet loopback

auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp 0
</pre>

To enable DHCP and get QEMU to use the bridge we've created above, run:

<pre>
# Install the bridge tools
apk add bridge

# Load kernel modules needed for KVM bridging.
printf 'tun\ntap\n' >> /etc/modules

# Allow Qemu to use our bridge.
echo 'allow br0' > /etc/qemu/bridge.conf

# Write some sysctl knobs to allow bridging to work.
printf '# Enable bridge forwarding.
net.ipv4.conf.br0_bc_forwarding=1
# Ignore iptables on bridge interfaces.
net.bridge.bridge-nf-call-iptables=0
' >> /etc/sysctl.d/bridging.conf

# Apply sysctl config edits.
sysctl -p
</pre>

After a ''reboot'', you can use the bridge like so (assuming you have a ''qcow2'' image named ''felix-pojtigners-theia.qcow2''):

<pre>
qemu-system-x86_64 -m 4096 -accel kvm -net nic -net bridge,br=br0 -boot d -drive format=qcow2,file=felix-pojtingers-theia.qcow2
</pre>

If you don't get a DHCP response for the guest machine (assuming you have a DHCP server running on the physical network that ''eth0'' is connected to), you can debug with ''tshark'':

<pre>
tshark -i eth0 -Y "bootp.option.type == 53"
</pre>

Talk:Bridge

2022-08-15T17:43:20Z

Winny: Add topic about KVM vs QEMU overlap

== KVM vs QEMU ==

Wanted to make a note- it appears the QEMU instructions work fine for libvirt (KVM). Is there any reason to include both set of instructions? Merge? — [[User:Winny|Winny]] ([[User talk:Winny|talk]]) 17:43, 15 August 2022 (UTC)

Bridge

2022-08-15T17:41:18Z

Winny: /* Little script to allow dhcp over iptables */ remove no-operation script

[[Category:Networking]]
This document describes how to configure a [http://en.wikipedia.org/wiki/Bridging_%28networking%29 network bridge] interface in Alpine Linux.

== Using brctl ==
Bridges are managed manually with the '''brctl''' command.
<pre>
Usage: brctl COMMAND [BRIDGE [INTERFACE]]

Manage ethernet bridges

Commands:
show Show a list of bridges
addbr BRIDGE Create BRIDGE
delbr BRIDGE Delete BRIDGE
addif BRIDGE IFACE Add IFACE to BRIDGE
delif BRIDGE IFACE Delete IFACE from BRIDGE
setageing BRIDGE TIME Set ageing time
setfd BRIDGE TIME Set bridge forward delay
sethello BRIDGE TIME Set hello time
setmaxage BRIDGE TIME Set max message age
setpathcost BRIDGE COST Set path cost
setportprio BRIDGE PRIO Set port priority
setbridgeprio BRIDGE PRIO Set bridge priority
stp BRIDGE [1|0] STP on/off
</pre>

To manually create bridge interface br0:
{{Cmd|brctl addbr br0}}

To add interface eth0 and eth1 to br0:
{{Cmd|brctl addif br0 eth0
brctl addif br0 eth1}}

Note: You need to set the link status to ''up'' on the added interfaces.
{{Cmd|ip link set dev eth0 up
ip link set dev eth1 up}}

[[Category:Networking]]

== Configuration file ==
Install the scripts that configure the bridge.
{{Cmd|apk add bridge}}

Bridging is then configured in ''/etc/network/interfaces'' with the ''bridge-ports'' keyword.
{{Warning|You normally don't assign ip addresses to the bridged interfaces (eth0 and eth1 in our example) but to the bridge itself (br0).}}

In this example the address 192.168.0.1/24 is used.

<pre>
auto br0
iface br0 inet static
bridge-ports eth0 eth1
bridge-stp 0
address 192.168.0.1
netmask 255.255.255.0
</pre>

You can set the various options with these keywords:
; bridge-ports
: Set bridge ports (ethX) or none for no physical interfaces
; bridge-aging
: Set ageing time
; bridge-fd
: Set bridge forward delay
; bridge-hello
: Set hello time
; bridge-maxage
: Set bridge max message age
; bridge-pathcost
: Set path cost
; bridge-portprio
: Set port priority
; bridge-bridgeprio
: Set bridge priority
; bridge-stp
: STP on/off

== Using pre-up/post-down ==
If you want be able to control the bridge interfaces individually, you need to use pre-up/post-down hooks.

Example ''/etc/network/interfaces'':

<pre>
auto br0
iface br0 inet static
pre-up brctl addbr br0
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
address 192.168.0.253
netmask 255.255.255.0
gateway 192.168.0.254
post-down brctl delbr br0

auto eth0
iface eth0 inet manual
up ip link set $IFACE up
up brctl addif br0 $IFACE
down brctl delif br0 $IFACE || true
down ip link set $IFACE down

auto eth1
iface eth1 inet manual
up ip link set $IFACE up
up brctl addif br0 $IFACE
down brctl delif br0 $IFACE || true
down ip link set $IFACE down
</pre>

That way, you create br0 with: ifup br0. You can add/remove
individual interfaces to the bridge with ifup eth0, ifdown eth0.

== Bridging for a Xen dom0 ==
Bridging in a dom0 is a bit specific as it consists in bridging a real interface (i.e. ethX) with a virtual interface (i.e. vifX.Y).
At bridge creation time, the virtual interface does not exist and will be added by the Xen toolstack when a domU is booting (see Xen documentation on how to link the virtual interface to the correct bridge).

;Particulars :
- the bridge consists of a single physical interface 
- the physical interface does not have an IP and is configured manually 
- the bridge will have the IP address and will be auto, resulting in bringing up the physical interface 

This translates to a sample config :

Example ''/etc/network/interfaces'':

<pre>
auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
address 192.168.0.253
netmask 255.255.255.0
gateway 192.168.0.254
bridge_ports eth0
bridge_stp 0
</pre>

After the domU OS is started, the virtual interface wil be added and the working bridge can be checked with
<pre>
brctl show

ifconfig -a
</pre>

== Bridging for KVM ==

Example ''/etc/network/interfaces'':

{{Note|I personally remove the eth0 declaration without any issue.}}
<pre>
auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp 0
</pre>

=== Little script to allow dhcp over iptables ===
{{Note|I tried the Using pre-up/post-down as mentionned in #3, but it didn't work well for me }}
{{Note|Usually it will be in /etc/rc.local as mentioned [https://wiki.libvirt.org/page/Networking#Debian.2FUbuntu_Bridging here] }}

<pre>
# Run local.d scripts on boot.
rc-update add local

# Write the script.
cat >> /etc/local.d/iptables_dhcp_kvm.start << EOM
echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
exit 0
EOM

# local.d script must be executable.
chmod a+x /etc/local.d/iptables_dhcp_kvm.start
</pre>

== Bridging for QEMU ==

Replace ''/etc/network/interfaces'' with the following:

<pre>
auto lo
iface lo inet loopback

auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp 0
</pre>

To enable DHCP and get QEMU to use the bridge we've created above, run:

<pre>
# Install the bridge tools
apk add bridge

# Load kernel modules needed for KVM bridging.
printf 'tun\ntap\n' >> /etc/modules

# Allow Qemu to use our bridge.
echo 'allow br0' > /etc/qemu/bridge.conf

# Write some sysctl knobs to allow bridging to work.
printf '# Enable bridge forwarding.
net.ipv4.conf.br0_bc_forwarding=1
# Ignore iptables on bridge interfaces.
net.bridge.bridge-nf-call-iptables=0
' >> /etc/sysctl.d/bridging.conf

# Apply sysctl config edits.
sysctl -p
</pre>

After a ''reboot'', you can use the bridge like so (assuming you have a ''qcow2'' image named ''felix-pojtigners-theia.qcow2''):

<pre>
qemu-system-x86_64 -m 4096 -accel kvm -net nic -net bridge,br=br0 -boot d -drive format=qcow2,file=felix-pojtingers-theia.qcow2
</pre>

If you don't get a DHCP response for the guest machine (assuming you have a DHCP server running on the physical network that ''eth0'' is connected to), you can debug with ''tshark'':

<pre>
tshark -i eth0 -Y "bootp.option.type == 53"
</pre>

Bridge

2022-08-15T17:37:23Z

Winny: remove references to "older versions" of alpine. 2.4 is last released 2012, alpine project doesn't support it, nor should we

[[Category:Networking]]
This document describes how to configure a [http://en.wikipedia.org/wiki/Bridging_%28networking%29 network bridge] interface in Alpine Linux.

== Using brctl ==
Bridges are managed manually with the '''brctl''' command.
<pre>
Usage: brctl COMMAND [BRIDGE [INTERFACE]]

Manage ethernet bridges

Commands:
show Show a list of bridges
addbr BRIDGE Create BRIDGE
delbr BRIDGE Delete BRIDGE
addif BRIDGE IFACE Add IFACE to BRIDGE
delif BRIDGE IFACE Delete IFACE from BRIDGE
setageing BRIDGE TIME Set ageing time
setfd BRIDGE TIME Set bridge forward delay
sethello BRIDGE TIME Set hello time
setmaxage BRIDGE TIME Set max message age
setpathcost BRIDGE COST Set path cost
setportprio BRIDGE PRIO Set port priority
setbridgeprio BRIDGE PRIO Set bridge priority
stp BRIDGE [1|0] STP on/off
</pre>

To manually create bridge interface br0:
{{Cmd|brctl addbr br0}}

To add interface eth0 and eth1 to br0:
{{Cmd|brctl addif br0 eth0
brctl addif br0 eth1}}

Note: You need to set the link status to ''up'' on the added interfaces.
{{Cmd|ip link set dev eth0 up
ip link set dev eth1 up}}

[[Category:Networking]]

== Configuration file ==
Install the scripts that configure the bridge.
{{Cmd|apk add bridge}}

Bridging is then configured in ''/etc/network/interfaces'' with the ''bridge-ports'' keyword.
{{Warning|You normally don't assign ip addresses to the bridged interfaces (eth0 and eth1 in our example) but to the bridge itself (br0).}}

In this example the address 192.168.0.1/24 is used.

<pre>
auto br0
iface br0 inet static
bridge-ports eth0 eth1
bridge-stp 0
address 192.168.0.1
netmask 255.255.255.0
</pre>

You can set the various options with these keywords:
; bridge-ports
: Set bridge ports (ethX) or none for no physical interfaces
; bridge-aging
: Set ageing time
; bridge-fd
: Set bridge forward delay
; bridge-hello
: Set hello time
; bridge-maxage
: Set bridge max message age
; bridge-pathcost
: Set path cost
; bridge-portprio
: Set port priority
; bridge-bridgeprio
: Set bridge priority
; bridge-stp
: STP on/off

== Using pre-up/post-down ==
If you want be able to control the bridge interfaces individually, you need to use pre-up/post-down hooks.

Example ''/etc/network/interfaces'':

<pre>
auto br0
iface br0 inet static
pre-up brctl addbr br0
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
address 192.168.0.253
netmask 255.255.255.0
gateway 192.168.0.254
post-down brctl delbr br0

auto eth0
iface eth0 inet manual
up ip link set $IFACE up
up brctl addif br0 $IFACE
down brctl delif br0 $IFACE || true
down ip link set $IFACE down

auto eth1
iface eth1 inet manual
up ip link set $IFACE up
up brctl addif br0 $IFACE
down brctl delif br0 $IFACE || true
down ip link set $IFACE down
</pre>

That way, you create br0 with: ifup br0. You can add/remove
individual interfaces to the bridge with ifup eth0, ifdown eth0.

== Bridging for a Xen dom0 ==
Bridging in a dom0 is a bit specific as it consists in bridging a real interface (i.e. ethX) with a virtual interface (i.e. vifX.Y).
At bridge creation time, the virtual interface does not exist and will be added by the Xen toolstack when a domU is booting (see Xen documentation on how to link the virtual interface to the correct bridge).

;Particulars :
- the bridge consists of a single physical interface 
- the physical interface does not have an IP and is configured manually 
- the bridge will have the IP address and will be auto, resulting in bringing up the physical interface 

This translates to a sample config :

Example ''/etc/network/interfaces'':

<pre>
auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
address 192.168.0.253
netmask 255.255.255.0
gateway 192.168.0.254
bridge_ports eth0
bridge_stp 0
</pre>

After the domU OS is started, the virtual interface wil be added and the working bridge can be checked with
<pre>
brctl show

ifconfig -a
</pre>

== Bridging for KVM ==

Example ''/etc/network/interfaces'':

{{Note|I personally remove the eth0 declaration without any issue.}}
<pre>
auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp 0
</pre>

=== Little script to allow dhcp over iptables ===
{{Note|I tried the Using pre-up/post-down as mentionned in #3, but it didn't work well for me }}
{{Note|Usually it will be in /etc/rc.local as mentioned [https://wiki.libvirt.org/page/Networking#Debian.2FUbuntu_Bridging here] }}

<pre>
rc-update add local
</pre>

<pre>
cat >> /etc/local.d/iptables_dhcp_kvm.start << EOM
echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
exit 0
EOM
</pre>

<pre>
cat >> /etc/local.d/iptables_dhcp_kvm.stop << EOM
exit 0
EOM
</pre>

<pre>
chmod +x /etc/local.d/iptables_dhcp_kvm.*
</pre>

== Bridging for QEMU ==

Replace ''/etc/network/interfaces'' with the following:

<pre>
auto lo
iface lo inet loopback

auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp 0
</pre>

To enable DHCP and get QEMU to use the bridge we've created above, run:

<pre>
# Install the bridge tools
apk add bridge

# Load kernel modules needed for KVM bridging.
printf 'tun\ntap\n' >> /etc/modules

# Allow Qemu to use our bridge.
echo 'allow br0' > /etc/qemu/bridge.conf

# Write some sysctl knobs to allow bridging to work.
printf '# Enable bridge forwarding.
net.ipv4.conf.br0_bc_forwarding=1
# Ignore iptables on bridge interfaces.
net.bridge.bridge-nf-call-iptables=0
' >> /etc/sysctl.d/bridging.conf

# Apply sysctl config edits.
sysctl -p
</pre>

After a ''reboot'', you can use the bridge like so (assuming you have a ''qcow2'' image named ''felix-pojtigners-theia.qcow2''):

<pre>
qemu-system-x86_64 -m 4096 -accel kvm -net nic -net bridge,br=br0 -boot d -drive format=qcow2,file=felix-pojtingers-theia.qcow2
</pre>

If you don't get a DHCP response for the guest machine (assuming you have a DHCP server running on the physical network that ''eth0'' is connected to), you can debug with ''tshark'':

<pre>
tshark -i eth0 -Y "bootp.option.type == 53"
</pre>

Bridge

2022-08-15T17:35:19Z

Winny: /* Configuration file */ make it more clean one should '''not''' set addresses on bridge members, only on the bridge itself

[[Category:Networking]]
This document describes how to configure a [http://en.wikipedia.org/wiki/Bridging_%28networking%29 network bridge] interface in Alpine Linux.

== Using brctl ==
Bridges are managed manually with the '''brctl''' command.
<pre>
Usage: brctl COMMAND [BRIDGE [INTERFACE]]

Manage ethernet bridges

Commands:
show Show a list of bridges
addbr BRIDGE Create BRIDGE
delbr BRIDGE Delete BRIDGE
addif BRIDGE IFACE Add IFACE to BRIDGE
delif BRIDGE IFACE Delete IFACE from BRIDGE
setageing BRIDGE TIME Set ageing time
setfd BRIDGE TIME Set bridge forward delay
sethello BRIDGE TIME Set hello time
setmaxage BRIDGE TIME Set max message age
setpathcost BRIDGE COST Set path cost
setportprio BRIDGE PRIO Set port priority
setbridgeprio BRIDGE PRIO Set bridge priority
stp BRIDGE [1|0] STP on/off
</pre>

To manually create bridge interface br0:
{{Cmd|brctl addbr br0}}

To add interface eth0 and eth1 to br0:
{{Cmd|brctl addif br0 eth0
brctl addif br0 eth1}}

Note: You need to set the link status to ''up'' on the added interfaces.
{{Cmd|ip link set dev eth0 up
ip link set dev eth1 up}}

[[Category:Networking]]

== Configuration file ==
{{Note|This requires Alpine Linux v2.4 or newer}}
Install the scripts that configure the bridge.
{{Cmd|apk add bridge}}

Bridging is then configured in ''/etc/network/interfaces'' with the ''bridge-ports'' keyword.
{{Warning|You normally don't assign ip addresses to the bridged interfaces (eth0 and eth1 in our example) but to the bridge itself (br0).}}

In this example the address 192.168.0.1/24 is used.

<pre>
auto br0
iface br0 inet static
bridge-ports eth0 eth1
bridge-stp 0
address 192.168.0.1
netmask 255.255.255.0
</pre>

You can set the various options with these keywords:
; bridge-ports
: Set bridge ports (ethX) or none for no physical interfaces
; bridge-aging
: Set ageing time
; bridge-fd
: Set bridge forward delay
; bridge-hello
: Set hello time
; bridge-maxage
: Set bridge max message age
; bridge-pathcost
: Set path cost
; bridge-portprio
: Set port priority
; bridge-bridgeprio
: Set bridge priority
; bridge-stp
: STP on/off

== Using pre-up/post-down ==
For older versions of Alpine Linux, or if you want be able to control the bridge interfaces individually, you need to use pre-up/post-down hooks.

Example ''/etc/network/interfaces'':

<pre>
auto br0
iface br0 inet static
pre-up brctl addbr br0
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
address 192.168.0.253
netmask 255.255.255.0
gateway 192.168.0.254
post-down brctl delbr br0

auto eth0
iface eth0 inet manual
up ip link set $IFACE up
up brctl addif br0 $IFACE
down brctl delif br0 $IFACE || true
down ip link set $IFACE down

auto eth1
iface eth1 inet manual
up ip link set $IFACE up
up brctl addif br0 $IFACE
down brctl delif br0 $IFACE || true
down ip link set $IFACE down
</pre>

That way, you create br0 with: ifup br0. You can add/remove
individual interfaces to the bridge with ifup eth0, ifdown eth0.

== Bridging for a Xen dom0 ==
Bridging in a dom0 is a bit specific as it consists in bridging a real interface (i.e. ethX) with a virtual interface (i.e. vifX.Y).
At bridge creation time, the virtual interface does not exist and will be added by the Xen toolstack when a domU is booting (see Xen documentation on how to link the virtual interface to the correct bridge).

;Particulars :
- the bridge consists of a single physical interface 
- the physical interface does not have an IP and is configured manually 
- the bridge will have the IP address and will be auto, resulting in bringing up the physical interface 

This translates to a sample config :

Example ''/etc/network/interfaces'':

<pre>
auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
address 192.168.0.253
netmask 255.255.255.0
gateway 192.168.0.254
bridge_ports eth0
bridge_stp 0
</pre>

After the domU OS is started, the virtual interface wil be added and the working bridge can be checked with
<pre>
brctl show

ifconfig -a
</pre>

== Bridging for KVM ==

Example ''/etc/network/interfaces'':

{{Note|I personally remove the eth0 declaration without any issue.}}
<pre>
auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp 0
</pre>

=== Little script to allow dhcp over iptables ===
{{Note|I tried the Using pre-up/post-down as mentionned in #3, but it didn't work well for me }}
{{Note|Usually it will be in /etc/rc.local as mentioned [https://wiki.libvirt.org/page/Networking#Debian.2FUbuntu_Bridging here] }}

<pre>
rc-update add local
</pre>

<pre>
cat >> /etc/local.d/iptables_dhcp_kvm.start << EOM
echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
exit 0
EOM
</pre>

<pre>
cat >> /etc/local.d/iptables_dhcp_kvm.stop << EOM
exit 0
EOM
</pre>

<pre>
chmod +x /etc/local.d/iptables_dhcp_kvm.*
</pre>

== Bridging for QEMU ==

Replace ''/etc/network/interfaces'' with the following:

<pre>
auto lo
iface lo inet loopback

auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp 0
</pre>

To enable DHCP and get QEMU to use the bridge we've created above, run:

<pre>
# Install the bridge tools
apk add bridge

# Load kernel modules needed for KVM bridging.
printf 'tun\ntap\n' >> /etc/modules

# Allow Qemu to use our bridge.
echo 'allow br0' > /etc/qemu/bridge.conf

# Write some sysctl knobs to allow bridging to work.
printf '# Enable bridge forwarding.
net.ipv4.conf.br0_bc_forwarding=1
# Ignore iptables on bridge interfaces.
net.bridge.bridge-nf-call-iptables=0
' >> /etc/sysctl.d/bridging.conf

# Apply sysctl config edits.
sysctl -p
</pre>

After a ''reboot'', you can use the bridge like so (assuming you have a ''qcow2'' image named ''felix-pojtigners-theia.qcow2''):

<pre>
qemu-system-x86_64 -m 4096 -accel kvm -net nic -net bridge,br=br0 -boot d -drive format=qcow2,file=felix-pojtingers-theia.qcow2
</pre>

If you don't get a DHCP response for the guest machine (assuming you have a DHCP server running on the physical network that ''eth0'' is connected to), you can debug with ''tshark'':

<pre>
tshark -i eth0 -Y "bootp.option.type == 53"
</pre>

Bridge

2022-08-15T17:31:43Z

Winny: /* Bridging for QEMU */ fixup the shell script for readability + save the iptables sysctl knob

[[Category:Networking]]
This document describes how to configure a [http://en.wikipedia.org/wiki/Bridging_%28networking%29 network bridge] interface in Alpine Linux.

== Using brctl ==
Bridges are managed manually with the '''brctl''' command.
<pre>
Usage: brctl COMMAND [BRIDGE [INTERFACE]]

Manage ethernet bridges

Commands:
show Show a list of bridges
addbr BRIDGE Create BRIDGE
delbr BRIDGE Delete BRIDGE
addif BRIDGE IFACE Add IFACE to BRIDGE
delif BRIDGE IFACE Delete IFACE from BRIDGE
setageing BRIDGE TIME Set ageing time
setfd BRIDGE TIME Set bridge forward delay
sethello BRIDGE TIME Set hello time
setmaxage BRIDGE TIME Set max message age
setpathcost BRIDGE COST Set path cost
setportprio BRIDGE PRIO Set port priority
setbridgeprio BRIDGE PRIO Set bridge priority
stp BRIDGE [1|0] STP on/off
</pre>

To manually create bridge interface br0:
{{Cmd|brctl addbr br0}}

To add interface eth0 and eth1 to br0:
{{Cmd|brctl addif br0 eth0
brctl addif br0 eth1}}

Note: You need to set the link status to ''up'' on the added interfaces.
{{Cmd|ip link set dev eth0 up
ip link set dev eth1 up}}

[[Category:Networking]]

== Configuration file ==
{{Note|This requires Alpine Linux v2.4 or newer}}
Install the scripts that configure the bridge.
{{Cmd|apk add bridge}}

Bridging is then configured in ''/etc/network/interfaces'' with the ''bridge-ports'' keyword.
Note: You normally don't assign ip addresses to the bridged interfaces (eth0 and eth1 in our example) but to the bridge itself (br0).

In this example the address 192.168.0.1/24 is used.

<pre>
auto br0
iface br0 inet static
bridge-ports eth0 eth1
bridge-stp 0
address 192.168.0.1
netmask 255.255.255.0
</pre>

You can set the various options with these keywords:
; bridge-ports
: Set bridge ports (ethX) or none for no physical interfaces
; bridge-aging
: Set ageing time
; bridge-fd
: Set bridge forward delay
; bridge-hello
: Set hello time
; bridge-maxage
: Set bridge max message age
; bridge-pathcost
: Set path cost
; bridge-portprio
: Set port priority
; bridge-bridgeprio
: Set bridge priority
; bridge-stp
: STP on/off

== Using pre-up/post-down ==
For older versions of Alpine Linux, or if you want be able to control the bridge interfaces individually, you need to use pre-up/post-down hooks.

Example ''/etc/network/interfaces'':

<pre>
auto br0
iface br0 inet static
pre-up brctl addbr br0
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
pre-up echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
address 192.168.0.253
netmask 255.255.255.0
gateway 192.168.0.254
post-down brctl delbr br0

auto eth0
iface eth0 inet manual
up ip link set $IFACE up
up brctl addif br0 $IFACE
down brctl delif br0 $IFACE || true
down ip link set $IFACE down

auto eth1
iface eth1 inet manual
up ip link set $IFACE up
up brctl addif br0 $IFACE
down brctl delif br0 $IFACE || true
down ip link set $IFACE down
</pre>

That way, you create br0 with: ifup br0. You can add/remove
individual interfaces to the bridge with ifup eth0, ifdown eth0.

== Bridging for a Xen dom0 ==
Bridging in a dom0 is a bit specific as it consists in bridging a real interface (i.e. ethX) with a virtual interface (i.e. vifX.Y).
At bridge creation time, the virtual interface does not exist and will be added by the Xen toolstack when a domU is booting (see Xen documentation on how to link the virtual interface to the correct bridge).

;Particulars :
- the bridge consists of a single physical interface 
- the physical interface does not have an IP and is configured manually 
- the bridge will have the IP address and will be auto, resulting in bringing up the physical interface 

This translates to a sample config :

Example ''/etc/network/interfaces'':

<pre>
auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
address 192.168.0.253
netmask 255.255.255.0
gateway 192.168.0.254
bridge_ports eth0
bridge_stp 0
</pre>

After the domU OS is started, the virtual interface wil be added and the working bridge can be checked with
<pre>
brctl show

ifconfig -a
</pre>

== Bridging for KVM ==

Example ''/etc/network/interfaces'':

{{Note|I personally remove the eth0 declaration without any issue.}}
<pre>
auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp 0
</pre>

=== Little script to allow dhcp over iptables ===
{{Note|I tried the Using pre-up/post-down as mentionned in #3, but it didn't work well for me }}
{{Note|Usually it will be in /etc/rc.local as mentioned [https://wiki.libvirt.org/page/Networking#Debian.2FUbuntu_Bridging here] }}

<pre>
rc-update add local
</pre>

<pre>
cat >> /etc/local.d/iptables_dhcp_kvm.start << EOM
echo 0 > /proc/sys/net/bridge/bridge-nf-call-arptables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
exit 0
EOM
</pre>

<pre>
cat >> /etc/local.d/iptables_dhcp_kvm.stop << EOM
exit 0
EOM
</pre>

<pre>
chmod +x /etc/local.d/iptables_dhcp_kvm.*
</pre>

== Bridging for QEMU ==

Replace ''/etc/network/interfaces'' with the following:

<pre>
auto lo
iface lo inet loopback

auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp 0
</pre>

To enable DHCP and get QEMU to use the bridge we've created above, run:

<pre>
# Install the bridge tools
apk add bridge

# Load kernel modules needed for KVM bridging.
printf 'tun\ntap\n' >> /etc/modules

# Allow Qemu to use our bridge.
echo 'allow br0' > /etc/qemu/bridge.conf

# Write some sysctl knobs to allow bridging to work.
printf '# Enable bridge forwarding.
net.ipv4.conf.br0_bc_forwarding=1
# Ignore iptables on bridge interfaces.
net.bridge.bridge-nf-call-iptables=0
' >> /etc/sysctl.d/bridging.conf

# Apply sysctl config edits.
sysctl -p
</pre>

After a ''reboot'', you can use the bridge like so (assuming you have a ''qcow2'' image named ''felix-pojtigners-theia.qcow2''):

<pre>
qemu-system-x86_64 -m 4096 -accel kvm -net nic -net bridge,br=br0 -boot d -drive format=qcow2,file=felix-pojtingers-theia.qcow2
</pre>

If you don't get a DHCP response for the guest machine (assuming you have a DHCP server running on the physical network that ''eth0'' is connected to), you can debug with ''tshark'':

<pre>
tshark -i eth0 -Y "bootp.option.type == 53"
</pre>

KVM

2022-08-15T17:23:49Z

Winny: make external links to alpinewiki internal (See also Help:Editing)

[https://www.linux-kvm.org/page/Main_Page KVM] is an free and open source virtualization solution in a kernel module. Although it is often simply referred to as KVM, the actual hypervisor is [https://www.qemu.org QEMU]. QEMU runs from user-space, but can integrate with KVM, providing better performance by leveraging the hardware from kernel-space. QEMU can virtualize x86, PowerPC, and S390 guests, amongst others. [https://libvirt.org Libvirt] is a management framework that integrates with QEMU/KVM, [[LXC]], [[Xen_Dom0|Xen]] and others.

== Installation ==
The following commands provide '''libvirt''' as well as '''QEMU with emulation for x86_64''' and '''qemu-img''', a necessary component for using various disk formats such as qcow2. Without qemu-img, only raw disks are available. It can also convert images between several formats like vhdx and vmdk. It also provides the metapackage '''qemu-modules''', which provides subpackages needed for special features. In versions of Alpine before 3.13.0 these features were covered by '''QEMU with emulation for x86_64'''.
{{Cmd|<nowiki># apk add libvirt-daemon qemu-img qemu-system-x86_64 qemu-modules openrc
# rc-update add libvirtd</nowiki>}}

== Networking ==
By default, libvirt uses NAT for VM connectivity. If you want to use the default configuration, you need to load the tun module.
{{Cmd|# modprobe tun}}
{{Cmd|add tun to autostart: # echo "tun" >> /etc/modules-load.d/tun.conf}}

To make the tun module load on boot, use this command:
{{Cmd|# cat /etc/modules {{!}} grep tun {{!}}{{!}} echo tun >> /etc/modules}}

If you prefer bridging a guest over your Ethernet interface, you need to make a [[Bridge#Configuration_file|bridge]].

It's quite common to use bridges with KVM environments. But when IPv6 is used, Alpine will assign itself a link-local address as well as an SLAAC address in case there's a router sending Router Advertisements. You don't want this because you don't want to have the KVM host an IP address in every network it serves to guests. Unfortunately IPv6 can not just be disabled for the bridge via a sysctl configuration file, because the bridge might not be up when the sysctl config is applied during boot. What works is to put a post-up hook into the /etc/network/interfaces file like this:
auto brlan
iface brlan inet manual
bridge-ports eth1.5
bridge-stp 0
post-up ip -6 a flush dev brlan; sysctl -w net.ipv6.conf.brlan.disable_ipv6=1

== Management ==
For non-root management, you will need to add your user to the libvirt group.
{{Cmd|# addgroup user libvirt}}

You can use libvirt's virsh at the CLI. It can execute commands as well as run as an interactive shell. Read its manual page and/or use the "help" command for more info. Some basic commands are:

{{Cmd|<nowiki>virsh help
virsh list --all
virsh start $domain
virsh shutdown $domain</nowiki>
}}

The libvirt project provides a GUI for managing hosts, called virt-manager. It handles local systems as well as remote ones via SSH.
{{Cmd|<nowiki># apk add dbus polkit virt-manager terminus-font
# rc-update add dbus</nowiki>}}

In order to use libvirtd to remotely control KVM over ssh PolicyKit needs a .pkla informing it that this is allowed.
Write the following file to /etc/polkit-1/localauthority/50-local.d/50-libvirt-ssh-remote-access-policy.pkla
{{Cmd|<nowiki>[Remote libvirt SSH access]
Identity=unix-group:libvirt
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes</nowiki>
}}

== Guest lifecycle management ==
The libvirt-guests service (available from Alpine 3.13.5) allows running guests to be automatically suspended or shut down when the host is shut down or rebooted.

The service is configured in /etc/conf.d/libvirt-guests. Enable the service with {{Cmd|# rc-update add libvirt-guests}}

== vfio ==

VFIO is more flexible way to do PCI passthrough. Let's suppose you want to use following ethernet card as PCI device in a VM.

# lspci | grep 02:00.0
02:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
# lspci -n -s 02:00.0
02:00.0 0200: 8086:10c9 (rev 01)

First, create ''/etc/mkinitfs/features.d/vfio.modules'' with the following content, so mkinitfs includes the VFIO modules in the initramfs.

kernel/drivers/vfio/vfio.ko.*
kernel/drivers/vfio/vfio_virqfd.ko.*
kernel/drivers/vfio/vfio_iommu_type1.ko.*
kernel/drivers/vfio/pci/vfio-pci.ko.*

Add ''vfio'' the the list of features in ''/etc/mkinitfs/mkinitfs.conf''.

Modify following file to instruct ''mkinitfs'' to load following module with the options and rebuild kernel ramdisk.

# cat /etc/modprobe.d/vfio.conf <<EOF
options vfio-pci ids=8086:10c9
options vfio_iommu_type1 allow_unsafe_interrupts=1
softdep igb pre: vfio-pci
EOF
# mkinitfs

Now we need to edit the "default_kernel_opts" and "modules" sections in the update-extlinux.conf file. Edit the "default_kernel_opts" to include ''intel_iommu=o iommu=pt'' for Intel platform (AMD uses ''amd_iommu=on''), and add the VFIO modules to the "modules" section.

# grep '^default_kernel_opts\|^modules' /etc/update-extlinux.conf
default_kernel_opts="quiet rootfstype=ext4 intel_iommu=on iommu=pt"
modules=sd-mod,usb-storage,ext4,raid1,vfio,vfio-pci,vfio_iommu_type1,vfio_virqfd

For syslinux/extlinux, run:

# update-extlinux

For GRUB (which [https://git.alpinelinux.org/aports/tree/main/grub/alpine-mkconfig.patch#n9 now also uses] the update-extlinux.conf if present), run:

# grub-mkconfig -o /boot/grub/grub.cfg

Reboot and check dmesg.

# grep -i -e DMAR -e IOMMU /var/log/dmesg
[ 0.343795] DMAR: Host address width 36
[ 0.343797] DMAR: DRHD base: 0x000000fed90000 flags: 0x1
[ 0.343804] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap c90780106f0462 ecap f020e3
[ 0.343806] DMAR: RMRR base: 0x000000000ed000 end: 0x000000000effff
[ 0.343807] DMAR: RMRR base: 0x000000bf7ed000 end: 0x000000bf7fffff
[ 0.553830] iommu: Default domain type: Passthrough (set via kernel command line)
[ 0.902477] DMAR: No ATSR found
[ 0.902563] DMAR: dmar0: Using Queued invalidation
...
[ 0.903256] pci 0000:02:00.0: Adding to iommu group 12
...
[ 0.903768] DMAR: Intel(R) Virtualization Technology for Directed I/O

If you do not run libvirt VMs under ''root'' (''egrep '^#*user' /etc/libvirt/qemu.conf''), then you must have correct permission on ''/dev/vfio/<iommu_group>'', eg. ''/dev/vfio/12''. You have to tune ''/etc/mdev.conf'' or UDEV rules. Also note that if there are multiple PCI devices in the same iommu group, you always have to add all of them to the VM otherwise you'll get an error message like "Please ensure all devices within the iommu_group are bound to their vfio bus driver"

# virsh dumpxml vm01 | xmllint --xpath '//*/hostdev' -
<hostdev mode="subsystem" type="pci" managed="yes">
<driver name="vfio"/>
<source>
<address domain="0x0000" bus="0x02" slot="0x00" function="0x0"/>
</source>
<alias name="hostdev0"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x06" function="0x0"/>
</hostdev>
<hostdev mode="subsystem" type="pci" managed="yes">
<driver name="vfio"/>
<source>
<address domain="0x0000" bus="0x02" slot="0x00" function="0x1"/>
</source>
<alias name="hostdev1"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x08" function="0x0"/>
</hostdev>

If you directly use QEMU without libvirt and are trying to pass a GPU to your VM, you may get a "VFIO_MAP_DMA failed: Out of memory" error, when starting the VM as a non-root user. One way to fix it is to install the ''shadow'' package, and increase the amount of memory the user can lock via the ''/etc/security/limits.conf'' file:
{{Cmd|<nowiki># apk add shadow
# echo "youruser soft memlock RAMamount \
youruser hard memlock RAMamount" >> /etc/security/limits.conf
# reboot</nowiki>}}

Replace "youruser" with the user you wish to run the VM as, and "RAMamount" with how much RAM your VM will need (in KB). The exact amount may throw the same error in the end, so you probably want to increase this value by a few dozen MB (typically +40).

A lot of info on the [https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF Archwiki article for PCI passthrough via OVMF].

[[Category:Virtualization]]

Desktop environments and Window managers

2022-02-07T03:13:08Z

Winny: Remind the user they should add their user to the appropriate groups

{{TOC right}}

{{Tip|Be sure to add your user to <code>input</code> and <code>video</code> groups.}}

'''Alpine Linux''' has no official desktop. Older versions used Xfce, but now, all GUI and graphical interfaces are optional. many are available and is attempted to be listed below:

== Desktop environments ==

# [[Xfce]]
# [[LXQt]]
# [[KDE|KDE Plasma]]
# [[Gnome]]
# [[MATE]]

== [https://en.wikipedia.org/wiki/Stacking_window_manager Stacking (floating) window managers] ==

* X11:
** [[Openbox]]

* Wayland:
** [[Wayfire]]

== [https://en.wikipedia.org/wiki/Tiling_window_manager Tiling (dynamic) window managers] ==

* X11:

** [[Dwm]]

** [[AwesomeWM|Awesome Window Manager]]

* Wayland:

** [[ Sway ]]

== See Also ==
* [[Installation]]
* [[Alpine newbie]]
* [[Post installation]]
* [[Fonts]]

[[Category:Desktop]]
[[Category:Newbie]]