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

From Funtoo
< Install(Difference between pages)
Jump to navigation Jump to search
 
(two first cases for virtuals)
 
Line 1: Line 1:
=== Configurando seu sistema ===
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.
Como é esperado de uma distribuição Linux, Funtoo Linux tem seu compartilhamento de arquivos de configuração. O arquivo que absolutamente requer que você edite de forma a assegurar que o Funtoo Linux inicialize com sucesso é <code>/etc/fstab</code>. Os outros são opcionais.  


==== Utilizando o Nano ====
== 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.


O editor padrão incluso no ambiente chroot é chamado de <code>nano</code>. Para editar um dos arquivos abaixo, chame o nano como a seguir:
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.


<console>
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.
(chroot) # ##i##nano /etc/fstab
</console>


Quando estiver no editor, você pode utilizar as teclas de cetas para mover o cursor, e teclas comuns como backspace e delete funcionarão como esperado. Para salvar o arquivo, pressione Control-X, e responda <code>y</code> quando solicitado para salvar o buffer modificado se você gostaria de salvar suas alterações.
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.


==== Configuration Files ====
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.


Aqui estão uma lista completa de arquivos que você pode queres editar, dependendo de suas necessidades:
== When virtual packages can be used? ==
{{TableStart}}
For virtual package ebuild to work correctly, the two following requirements must be met:
<tr class="active"><th>Arquivo</th>
# 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.
<th>Preciso alter-á-lo?</th>
# 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.
<th>Descrição</th>
</tr><tr  class="danger">
<td><code>/etc/fstab</code></td>
<td>'''SIM - exigido'''</td>
<td>Pontos de montagem para todos os filesystems a serem utilizados no momento do boot. Esse arquivo deve refletir sua configuação de partição de disco. Vamos lhe guiar através da modificação desse arquivo abaixo.</td>
</tr><tr>
<td><code>/etc/localtime</code></td>
<td>''Talvez - recomendável''</td>
<td>Seu fuso horário (timezone), que será padrão ao UTC se não definido. Esse deve ser um link simbólico para algo localizado sob /usr/share/zoneinfo (ex. /usr/share/zoneinfo/America/Montreal) </td>
</tr><tr>
<td><code>/etc/make.conf</code> (symlink) - also known as:<br/><code>/etc/portage/make.conf</code></td>
<td>''Talvêz - recomendado''</td>
<td>Parâmetros utilizado pelo gcc (compilador), pelo portage, e pelo make. É uma boa ideia definir o MAKEOPTS. Isso é coberto mais para frente nessa documentação.</td>
</tr><tr>
<td><code>/etc/conf.d/hostname</code></td>
<td>''Talvez - recomendado''</td>
<td>Utilizado para definir o hostname do sistema. Defina a variável <code>hostname</code> como nome fully-qualified (com pontos, ex. <code>foo.funtoo.org</code>) se você tiver um. Caso contrário, defina para o hostname do sistema local (sem pontos, ex. <code>foo</code>). Padrões para <code>localhost</code> se não definido.</td>
</tr><tr>
<td><code>/etc/hosts</code></td>
<td>''Não''</td>
<td> Você não precisa mais definir manual o hostname nesse arquivo. Esse arquivo é gerado manualmente pelo <code>/etc/init.d/hostname</code>.</td>
</tr><tr>
<td><code>/etc/conf.d/keymaps</code></td>
<td>Opcional</td>
<td>Arquivo de configuração de mapeamento do teclado (fara console pseudo terminais). Configure se você não possui um teclado no padrão americano (non-US). Veja [[Pt-br/Funtoo_Linux_Localization|Localização do Funtoo Linux]].</td>
</tr><tr>
<td><code>/etc/conf.d/hwclock</code></td>
<td>Opcional</td>
<td>Como o tempo de clock do hardware mantido pela bateria (battery-backed) do sistema é interpretado [UTC ou hora local (local time)]. Linux utiliza o clock do hardware mantido pela bateria para inicializar a hora do sistema quando o sistema é inicializado.</td>
</tr><tr>
<td><code>/etc/conf.d/modules</code></td>
<td>Opcional</td>
<td>Módulos do Kernel para carregar automaticamente na inicialização do sistema. Tipicamente não exigido. Veja [[Additional Kernel Resources]] para mais informações.</td>
</tr><tr>
<td><code>/etc/conf.d/consolefont</code></td>
<td>Opcional</td>
<td>Lhe permite especificar a font padrão do console. Para aplicar essa font, habilite o serviço consolefont ao executar rc-update add consolefont.</td>
</tr><tr>
<td><code>profiles</code></td>
<td>Opcional</td>
<td>Algumas configurações úteis para o portage que podem ajudar a acelerar a configuração inicial.</td>
</tr>
{{TableEnd}}


Se você estiver instalando uma versão em Inglês do Funtoo Linux, você está com sorte desde que muitos dos arquivos de configuração pode ser utilizadas como é. Se estiver instalando para outra localidade, não se preocupe. Vamos lhe orientar através dos passos para a configuração necessária na página [[Pt-br/Funtoo_Linux_Localization|Localização do Funtoo Linux]], e se necessário, sempre há muito suporte amigável e útil. (Veja [[#Community portal|Community]])
Virtuals can not be used if the underlying packages don't provide binary compatibility at least between predictable range of versions.


Vamos seguir em frente e ver o que temos que fazer. Utilize <code>nano -w <name_of_file></code> para editar os arquivos -- o "<code>-w</code>" desabilita empacotamento de palavras (word-wrapping), que útil quando editar arquivos de configurações. Você pode copiar e colar a partir dos exemplos.
== Common uses for virtual packages ==
=== System components and services ===
Example: ''virtual/service-manager''


{{fancywarning|É importante editar seu arquivo <code>/etc/fstab</code> antes de você reinicializar! Você precisará modificar ambas as colunas  "fs" e "type" para equiparar as configurações para as suas partições e filesystems que você criou com o <code>gdisk</code> ou <code>fdisk</code>. Pulando esses podem impedir que o Funtoo Linux de inicializar com sucesso.}}
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.


==== /etc/fstab ====
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.


<code>/etc/fstab</code> é utilizado pelo comando <code>mount</code> que é executado quando seu sistema inicializa. Afirmações desse arquivo informam <code>mount</code> a respeito das partições a serem montadas e como elas são montadas. No intuito que o sistema inicialize devidamente, você deve editar <code>/etc/fstab</code> e assegurar de que isso reflita a configuração de partições que você utilizou anteriormente:
=== Tools provided by multiple packages ===
Example: ''virtual/eject''


<console>
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).
(chroot) # ##i##nano -w /etc/fstab
</console>


<pre>
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.
# The root filesystem should have a pass number of either 0 or 1.
# All other filesystems should have a pass number of 0 or greater than 1.
#
# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
#
# See the manpage fstab(5) for more information.
#
# <fs>     <mountpoint>  <type>  <opts>        <dump/pass>
 
/dev/sda1    /boot        ext2    noauto,noatime 1 2
/dev/sda2    none          swap    sw            0 0
/dev/sda3    /            ext4    noatime        0 1
#/dev/cdrom  /mnt/cdrom    auto    noauto,ro      0 0
</pre>
 
{{Note|Atualmente, noso <code>/etc/fstab</code> padrão tem o filesystem root como <code>/dev/sda4</code> e a partição swap como <code>/dev/sda3</code>. Esses precisarão ser alterados para <code>/dev/sda3</code> e <code>/dev/sda2</code>, respectivamente.}}
 
{{Note|Se você estiver utilizando UEFI para inicializar (boot), altere a linha <code>/dev/sda1</code> então ela diz <code>vfat</code> ao invés de <code>ext2</code>. Similarmente, certifique-se de que a linha <code>/dev/sda3</code> especifica ou <code>xfs</code> ou <code>ext4</code>, dependendo de qual filesystem você escolher em filesystem-creation time.}}
 
==== /etc/localtime ====
 
<code>/etc/localtime</code> é utilizado para especificar o fuso horário (timezone) em que sua sua máquina está, e os padrões para o UTC. Se você quiser que seu sistema Funtoo Linux utilize fuso horário, você deve substituir <code>/etc/localtime</code> por um link simbólico para o fuso horário que você deseja utilizar.
 
<console>
(chroot) # ##i##ln -sf /usr/share/zoneinfo/MST7MDT /etc/localtime
</console>
 
O comando acima define o fuso horário para montar o horário padrão (com horário de verão). Digite <code>ls /usr/share/zoneinfo</code> para verificar quais fuso horários estão disponíveis. Há também subdiretórios contendo fuso horários descritos por local.
 
==== /etc/make.conf ====
 
MAKEOPTS pode ser utilizado para definir quantas compilações paralelas devem ocorrer quando você compilar um pacote, que pode acelerar compilação significativamente. uma regra de thumb é o número de CPUs (ou CPU threads) em seu sistema mais um (plus one). Se por exemplo você possui um processador dual core sem [[wikipedia:Hyper-threading|hyper-threading]], então você definiria MAKEOPTS para 3:
 
<pre>
MAKEOPTS="-j3"
</pre>
 
Se você não estiver certo sobre quantos processadores/threads você possui, então utilize nproc para ajudá-lo.
<console>
(chroot) # ##i##nproc
16
</console>
 
Defina MAKEOPTS para esse número mais um:
 
<pre>
MAKEOPTS="-j17"
</pre>
 
Flgas USE definem qual funcionalidade está habilitada quando pacotes são construídos. Não é recomendado adicionar um monte dele durante a instalação; Você deve esperar até que obtenha um, sistema inicializável, funcional antes de alterar suas flags USE. Uma flag USE prefixada com um sinal de menos ("<code>-</code>") diz ao Portage para não utilizar a flag quando compilar. Um guia do Funtoo para as flags USE estarão disponíveis no futuro. Por hora, você pode descobrir mais informações sobre as flags USE no [http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=2&chap=2 Gentoo Handbook].
 
LINGUAS diz ao Portage em qual idioma local compilar o sistema e as aplicações (aqueles que utilizam variável LINGUAS como o OpenOffice). Geralmente não é necessário definir essa se você utiliza em inglês. Se você quiser um outro idioma tal qual francês (fr) ou Alemão (de), defina LINGUAS apropriadamente:
 
<pre>
LINGUAS="fr"
</pre>
 
==== /etc/conf.d/hwclock ====
Se você realizar dual-boot com Windows, você precisará editar esse arquivo e alterar o valor de '''clock''' de '''UTC''' para '''local''', por que o Windows definirá seu hardware clock para a hora local toda vêz que inicializar (boot) o Windows. Caso contrário você normalmente não precisaria editar esse arquivo.
<console>
(chroot) # ##i##nano -w /etc/conf.d/hwclock
</console>
 
==== Localization ====
 
By default, Funtoo Linux is configured with Unicode (UTF-8) enabled, and for the US English locale and keyboard. If you would like to configure your system to use a non-English locale or keyboard, see [[Funtoo Linux Localization]].

Revision as of 13:31, 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.