Difference between pages "Install/pt-br/Kernel" and "Virtual Packages"

From Funtoo
< Install(Difference between pages)
Jump to navigation Jump to search
 
 
Line 1: Line 1:
=== Configurando e instalando o kernel Linux ===
Virtual packages are special packages that correspond to a feature that can be satisfied by one or more package(s). This Wiki page aims to describe when and how to use them correctly, and what are their implications.


Agora é hora de construir e instalar um kernel Linux, o qual é o coração de qualquer sistema Funtoo Linux. O kernel é carregado pelo boot loader, and interfaces directly with your system's hardware, and allows regular (userspace) programs to run.
== Virtual packages, metapackages and package sets ==
Virtual packages, metapackages and package sets are similar concepts. However, they have a few important differences that make them fit for different use cases.


A kernel must be configured properly for your system's hardware, so that it supports your hard drives, file systems, network cards, and so on. More experienced Linux users can choose to install kernel sources and configure and install their own kernel. If you don't know how to do this, we provide ebuilds that will automatically build a "univeral" kernel, modules and initramfs for booting your system that supports all hardware. This is an extremely simple way of building a kernel that will get your system booted.
Virtual packages and metapackages are regular Funtoo packages (ebuilds) that install no files. Instead, they cause other packages to be installed by specifying them in their runtime dependencies. They can both be used in any context valid for regular packages. They can have multiple versions, slots and USE flags. They have to be located in an active repository, and once there they can be installed and uninstalled like regular packages.


What is our goal? To build a kernel that will recognize all the hardware in your system necessary for booting, so that you will be greeted by a friendly login prompt after installation is complete. These instructions will guide you through the process of installing a kernel the "easy" way -- without requiring user configuration, by using a "universal" kernel.
Package sets are not packages but special atoms supported by Portage. Package sets can only specify other packages, either via a static list or dynamically (e.g. via running Python code that determines the package list). Package sets can't be versioned and don't have USE flags. Package sets can be used alongside packages in emerge commands and other package sets but they can't be referenced inside regular packages. Package sets can be installed into user's system, located in repositories or created by user in Portage configuration.


==== Package Sets ====
Virtual packages represent a commonly used feature that can be provided by multiple different providers. Virtuals provide a convenient way of specifying all possible alternatives without having to update multiple ebuilds.


Before we install a kernel, we're going to cover a feature of Portage called package sets. Portage, the package manager/ports system for Funtoo Linux, will keep track of system packages as well as packages you have installed by calling <code>emerge</code> directly. These packages that are part of the base system are considered part of the "system" package set, while packages that you have installed by typing them on the command line (such as "gnome" in <code>emerge gnome</code>) will be added to the "world" package set. This provides an easy way to update your entire system.
Metapackages and package sets are used to represent lists of packages that user may want to install together. They provide a convenience for users, e.g. providing a shortcut to install all packages comprising a desktop environment.


However, sometimes it's nice to be able to update the kernel all by itself, or leave a kernel update out of your regular whole system update. To do this, we will create a new package set called "kernel".
== When virtual packages can be used? ==
For virtual package ebuild to work correctly, the two following requirements must be met:
# the virtual providers must be interchangeable at runtime with no consequences to the reverse dependencies. In other words, installing another provider and removing the currently used provider must not cause any breakage or require reverse dependencies to be rebuilt.
# Reverse dependencies need to have consistent, predictable requirements for the alternatives. In other words, the packages must not require a very specific versions of the alternatives.


==== Kernel Package Set ====
Virtuals can not be used if the underlying packages don't provide binary compatibility at least between predictable range of versions.


To create the kernel package set, perform the following steps:
== Common uses for virtual packages ==
=== System components and services ===
Example: ''virtual/service-manager''


<console>
One of the common uses for virtuals is to define abstract ''system services''. Those virtuals are not very specific on how those services are provided. They are mostly intended to be used in the @system package set, to ensure that the user system doesn't lack key components such as a service manager or a package manager.
(chroot) # ##i##mkdir /etc/portage/sets
(chroot) # ##i##echo sys-kernel/debian-sources > /etc/portage/sets/kernel
</console>


Now, we'll want to set a USE variable to tell <code>debian-sources</code> to build a "universal" kernel and initramfs for us, to take the guess-work out of getting Funtoo Linux booted. To do this, we're going to set the <code>binary</code> USE variable for <code>debian-sources</code>, as follows:
The providers for this kind of virtuals do not have to meet any specific requirements except for having a particular function. In particular, there's no requirement for common configuration or provided executables. The user is responsible for ensuring that the installed implementation is set up and working.


<console>
=== Tools provided by multiple packages ===
(chroot) # ##i##echo "sys-kernel/debian-sources binary" >> /etc/portage/package.use
Example: ''virtual/eject''
</console>


If USE variables are new to you, you'll be getting a lot more familiar with them as you use Funtoo Linux. At their essence, they are "switches" that you can set to configure options that can be built in to various packages. They're used to customize your Funtoo Linux system to meet your exact needs. We added support for a <code>binary</code> USE flag to the <code>debian-sources</code> ebuilds, as well as a few other of our kernel ebuilds, to make it easier for new users to get Funtoo Linux up and running.
This kind of virtuals is used when multiple packages may provide tools with the same names. The virtual is used in packages that rely on those tools being present, in particular when the tools are used at build-time of the package or are called by package's scripts (executables).


Now, when we just want to update our system's packages, we'll type <code>emerge -auDN @world</code>, and it will update our world set, leaving out the kernel. Likewise, when we just want to update our kernel, we'll type <code>emerge -au @kernel</code>, and it will update our kernel, leaving out the world set.
While the tools don't necessarily need to be fully compatible, they need to have a common basic usage. In particular, when a tool from one provider is replaced by a tool from another, the reverse dependencies must remain in working state, with no need for rebuilds or configuration adjustments.


==== Building the Kernel ====
=== Libraries with certain degree of ABI compatibility ===
Example: ''virtual/libudev''


{{Fancynote|1=
This kind of virtuals is to allow switching between multiple providers of a library. However, virtual can only be used when the various providers provide ABI-compatible variants of the same library.
See [[Funtoo Linux Kernels]] for a full list of kernels supported in Funtoo Linux. We recommend <code>debian-sources</code> for new users.}}


{{fancyimportant|1=
Virtual ebuild should have a separate version at least for every ABI version of the library. The ebuilds should have appropriate subslots and depend on respective subslots or versions of the provider that provide the library with necessary ABI. For example, virtual/libfoo-1 depends on specific versions of libfoo providers that provide libfoo.so.1, while virtual/libfoo-2 depends on versions providing libfoo.so.2. This guarantees that the reverse dependencies of the virtual will be rebuilt when the underlying library is upgraded.
<code>debian-sources</code> with <code>binary</code> USE flag requires at least 14GB free in <code>/var/tmp</code> and takes around 1 hour to build on a Intel Core i7 Processor.}}
 
Let's emerge our kernel:
 
<console>
(chroot) # ##i##emerge -1 @kernel
</console>
 
{{Important|Right now, the <code>-1</code> option is required to not add our <code>@kernel</code> set to <code>world-sets</code>. This allows you to emerge it independently from @world. If you forget to use this option, edit <code>/var/lib/portage/world-sets</code> and remove the <code>@kernel</code> line. This will prevent kernel updates from being included in @world updates.}}
 
Note that while use of the <code>binary</code> USE flag makes installing a working kernel extremely simple, it is one part of Funtoo Linux that takes a ''very'' long time to build from source, because it is building a kernel that supports ''all'' hardware that Linux supports! So, get the build started, and then let your machine compile. Slower machines can take up to several hours to build the kernel, and you'll want to make sure that you've set <code>MAKEOPTS</code> in <code>/etc/portage/make.conf</code> to the number of processing cores/threads (plus one) in your system before starting to build it as quickly as possible -- see the [[#/etc/portage/make.conf|/etc/portage/make.conf section]] if you forgot to do this.
 
{{fancynote|NVIDIA card users: the <code>binary</code> USE flag installs the Nouveau drivers which cannot be loaded at the same time as the proprietary drivers, and cannot be unloaded at runtime because of KMS. You need to blacklist it under <code>/etc/modprobe.d/</code>.}}
 
{{fancynote|For an overview of other kernel options for Funtoo Linux, see [[Funtoo Linux Kernels]]. There may be modules that the Debian kernel doesn't include, a situation where [http://www.funtoo.org/wiki/Funtoo_Linux_Kernels#Using_Debian-Sources_with_Genkernel genkernel] would be useful. Also be sure to see [[:Category:Hardware Compatibility|hardware compatibility]] information.}}
 
Once <code>emerge</code> completes, you'll have a brand new kernel and initramfs installed to <code>/boot</code>, plus kernel headers installed in <code>/usr/src/linux</code>, and you'll be ready to configure the boot loader to load these to boot your Funtoo Linux system.

Revision as of 20:24, February 7, 2015

Virtual packages are special packages that correspond to a feature that can be satisfied by one or more package(s). This Wiki page aims to describe when and how to use them correctly, and what are their implications.

Virtual packages, metapackages and package sets

Virtual packages, metapackages and package sets are similar concepts. However, they have a few important differences that make them fit for different use cases.

Virtual packages and metapackages are regular Funtoo packages (ebuilds) that install no files. Instead, they cause other packages to be installed by specifying them in their runtime dependencies. They can both be used in any context valid for regular packages. They can have multiple versions, slots and USE flags. They have to be located in an active repository, and once there they can be installed and uninstalled like regular packages.

Package sets are not packages but special atoms supported by Portage. Package sets can only specify other packages, either via a static list or dynamically (e.g. via running Python code that determines the package list). Package sets can't be versioned and don't have USE flags. Package sets can be used alongside packages in emerge commands and other package sets but they can't be referenced inside regular packages. Package sets can be installed into user's system, located in repositories or created by user in Portage configuration.

Virtual packages represent a commonly used feature that can be provided by multiple different providers. Virtuals provide a convenient way of specifying all possible alternatives without having to update multiple ebuilds.

Metapackages and package sets are used to represent lists of packages that user may want to install together. They provide a convenience for users, e.g. providing a shortcut to install all packages comprising a desktop environment.

When virtual packages can be used?

For virtual package ebuild to work correctly, the two following requirements must be met:

  1. the virtual providers must be interchangeable at runtime with no consequences to the reverse dependencies. In other words, installing another provider and removing the currently used provider must not cause any breakage or require reverse dependencies to be rebuilt.
  2. Reverse dependencies need to have consistent, predictable requirements for the alternatives. In other words, the packages must not require a very specific versions of the alternatives.

Virtuals can not be used if the underlying packages don't provide binary compatibility at least between predictable range of versions.

Common uses for virtual packages

System components and services

Example: virtual/service-manager

One of the common uses for virtuals is to define abstract system services. Those virtuals are not very specific on how those services are provided. They are mostly intended to be used in the @system package set, to ensure that the user system doesn't lack key components such as a service manager or a package manager.

The providers for this kind of virtuals do not have to meet any specific requirements except for having a particular function. In particular, there's no requirement for common configuration or provided executables. The user is responsible for ensuring that the installed implementation is set up and working.

Tools provided by multiple packages

Example: virtual/eject

This kind of virtuals is used when multiple packages may provide tools with the same names. The virtual is used in packages that rely on those tools being present, in particular when the tools are used at build-time of the package or are called by package's scripts (executables).

While the tools don't necessarily need to be fully compatible, they need to have a common basic usage. In particular, when a tool from one provider is replaced by a tool from another, the reverse dependencies must remain in working state, with no need for rebuilds or configuration adjustments.

Libraries with certain degree of ABI compatibility

Example: virtual/libudev

This kind of virtuals is to allow switching between multiple providers of a library. However, virtual can only be used when the various providers provide ABI-compatible variants of the same library.

Virtual ebuild should have a separate version at least for every ABI version of the library. The ebuilds should have appropriate subslots and depend on respective subslots or versions of the provider that provide the library with necessary ABI. For example, virtual/libfoo-1 depends on specific versions of libfoo providers that provide libfoo.so.1, while virtual/libfoo-2 depends on versions providing libfoo.so.2. This guarantees that the reverse dependencies of the virtual will be rebuilt when the underlying library is upgraded.

Retrieved from "https://www.funtoo.org/index.php?title=Install/pt-br/Kernel&oldid=8987"