Difference between pages "Install/pt-br/Partitioning" and "Ebuild Functions"

< Install(Difference between pages)
m (Tocadotux moved page Install/pt-br/Partitioning to Install/Partitioning/pt-br: Making as Paul advised me)
 
(Skipping over a function: use no-op for skipped phase function)
 
Line 1: Line 1:
 +
== Ebuild Functions ==
  
===Particionamento===
+
Ebuilds provide the ability to define various shell functions that are used to specify various actions relating to building and installing a source or binary package on a user's system. When an ebuild is emerged, the following functions are called, in order:
  
=== Prepare o Disco Rígido ===
+
* <tt>pkg_setup</tt> - variable intialization and sanity checks
 +
* <tt>src_unpack</tt>
 +
* <tt>src_prepare</tt>
 +
* <tt>src_configure</tt>
 +
* <tt>src_compile</tt>
 +
* <tt>src_install</tt>
  
==== Introdução ====
+
At this point, the files are ready to be "merged" into the live filesystem. This is when they are copied from the temporary build directory into <tt>/usr</tt>, etc. At this point, the following functions are executed:
  
Em tempos remotos, só havia um jeito de inicializar (boot)o computador compatível com a arquitetura PC. Todos os nossos desktops e servidores tinham uma BIOS padrão, todos os nossos hard drives utilizavam Master Boot Records, e eram particionados utilizando esquema de partição MBR. E nós gostávamos disso daquele jeito mesmo!
+
* <tt>pkg_preinst</tt>
 +
* (files are merged)
 +
* <tt>pkg_postinst</tt>
  
Então, depois veio os EFI e UEFI, que são firmware em novo-estilo projetados para inicializar sistemas, junto as tabelas de partição GPT para suportar discos superiores à 2.2TB. Tudo repentino, nós tínhamos uma variedade de opções para inicializar os sistemas Linux, tornando o que uma vez era um método único de encaixe de tudo  (one-method-fits-all) aproximar-se á algo muito mais complexo.
+
=== src_* functions ===
  
Vamos parar por um momento para rever as opções de boot disponíveis para você. Esse pequeno Guia utiliza, e recomenda, o método da BIOS à moda antiga inicializando e usando um MBR. Funciona. Não há nada de errado com ele. Se seu disco é do tamanho de  2TB ou menor, ele não vai impedir que você use toda a capacidade do seu disco, também.
+
Ebuild functions starting with <tt>src_</tt> are all related to creating the ebuild or package from source code/artifacts, and are defined below:
  
Mas, há alguns situações onde  o método da não é satisfatório. Se você obtiver um disco de tamando superior à 2TB, então partições MBR não o permitirão acessar todo o seu  armazenamento (storage). Então essa é uma rasão. Outra rasão é que há alguns então assim chamados  "PC" por aí afora que não suportam maias BIOS, e lhe força a utilizar o UEFI para inicializar. Então, sem compaixão pelas pessoas que se enquadram nessa situação, esse Guia de Instalação documenta boot pelo UEFI também.
+
==== src_unpack ====
  
Nossa recomandação ainda é ir pela moda antiga a não ser  que tenha resão para não. Chamamos esse método  de método '''BIOS + GRUB (MBR)'''. Esse é o método tradicional de configurar um PC para inicilizar o Linux.
+
<tt>src_unpack</tt> is intended to be used to unpack the source code/artifacts that will be used by the other <tt>src_*</tt> functions. With EAPI 1 and earlier, it is also used for patching/modifying the source artifacts to prepare them for building, but with EAPI 2 or later the <tt>src_prepare</tt> function should be used for this instead. When <tt>src_unpack</tt> starts, the current working directory is set to <tt>$WORKDIR</tt>, which is the directory within which all source code/artifacts should be expanded. Note that the variable <tt>$A</tt> is set to the names of all the unique source files/artifacts specified in <tt>SRC_URI</tt>, and they will all be available in <tt>$DISTDIR</tt> by the time <tt>src_unpack</tt> starts. Also note that if no <tt>src_unpack</tt> function is specified, <tt>ebuild.sh</tt> will execute the following function for <tt>src_unpack</tt> by default:
  
Se você precisa usar UEFI para inicilizar, recomendamos não utillizar de maneira alguma o MBR para boot, já que alguns sistemas suportam as some UEFI, mas outros não. Ao inves disso, recomendamos utilizar o UEFI para inicializar o GRUB, que carregará o Linux. Referimos a esse método como o método '''UEFI + GRUB (GPT)'''.
+
<pre>
 +
src_unpack() {
 +
  unpack ${A}
 +
}
 +
</pre>
  
E sim, há ainda mais, alguns aos quais estão documentados na página [[Boot Methods]]. Nós costumavamos recomendar um étodo '''BIOS + GRUB (GPT)''', mas esse não tem consistentemente suporte em uma variedade de hardware.
+
==== src_prepare ====
  
'''A grande pergunta é -- que método de boot eu devo usar?''' Aqui está como responder.
+
EAPI 2 and above support the <tt>src_prepare</tt> function, which is intended to be used for applying patches or making other modifications to the source code. When <tt>src_prepare</tt> starts, the current working directory is set to <tt>$S</tt>.
  
;Princípio nº 1 - Moda antiga (Old School): Se você pode inicializar com confiavelmente o System Rescue CD e ele exibe um menu inicial azul claro, você está inializando o CD usando a BIOS, e provavelmente você pode assim inicilizar o Funtoo Linux ussando a BIOS. Então, vá pela moda antiga e use a boot da BIO, ''a não ser que'' você tenha alguma resão para usar UEFI, tal qual ter um disco do tamando superior a 2.2TB. Nesse caso, veja o segundo Princípio nº 2, já que seu sistema pode ter suporte também à  boot UEFI.
+
==== src_configure ====
  
;Princípio nº 2 - Moderno (New School): Se você pode confiavelmente inicilizar o System Rescue CD e ele te exibe um menu inicial preto e branco -- parabens, seu sistema é configurado para suportar o boot via UEFI. Isso significa que você está pronto para instalar o install Funtoo Linux para inicializá-lo via UEFI. Seu sistema pode ainda ter suporte para inicilizar com a BIOS, mas  somente se for testado pela UEFI primeiro. Você pode dar uma bisbilhotada na sua configuração de boot pelo BIOS e brincar com isso.
+
EAPI 2 and above support the <tt>src_configure</tt> function, which is used to configure the source code prior to compilation. With EAPI 2 and above, the following default <tt>src_configure</tt> is defined if none is specified:
  
;Qual pe a Grande Diferença entra a Moda Antiga e a Moderna?: Aqui está a coisa. Se você for com as as partições MBR a moda antiga, sua partição <code>/boot</code> será um sistema de arquivos ext2, e você utilizará <code>fdisk</code> para criar suas partições MBR. Se você com as partições GPT e boot via UEFI, sua partição <code>/boot</code> será um sistema de arquivos vfat, por que isso é o que o UEFI é capaz de ler, e você utilizará <code>gdisk</code> para criar suas partiçẽos GP. E você instalará o GRUB um pouco diferente. É a respeito disso que tudo vem abaixo, em caso você estivesse curioso/a.
+
<pre>
 +
src_configure() {
 +
if [[ -x ${ECONF_SOURCE:-.}/configure ]] ; then
 +
econf
 +
fi
 +
}
 +
</pre>
  
{{Note|'''Algumas placas mãe pode aparentar suporte a UEFI, mas não suportam.''' Faça sua pesquisa. Por exemplo, O BIOS atribuído na minha Gigabyte GA-990FXA-UD7 rev 1.1 tem uma opção de abilitar o boot UEFI por CD/DVD. '''Isso não é o sufuciente para abilitar boot via UEFI pelo hard drives e instalar o Funtoo Linux.''' UEFI deve ter tanto para mídia removível (assim você pode inicializar o System Rescue CD utilizando o UEFI) quanto mídias fixas (assim você pode inicializar sua nova instalação do Funtoo Linux.) Revelá-se que revisões posteriores dessa placa (rev 3.0) tem um novo BIOS que suporta completamente o boot do UEFI.  Isso pode apontar para o terceiro princípio -- conheça teu hardware.}}
+
==== src_compile ====
  
==== O método a moda antiga (BIOS/MBR) ====
+
This function defines the steps necessary to compile source code. With EAPI 1 and earlier, this function is also used to configure the source code prior to compilation. However, starting with EAPI 2, the <tt>src_configure</tt> function must be used for configuration steps instead of bundling them inside <tt>src_compile</tt>. In addition, starting with EAPI 2, there is now a default <tt>src_compile</tt> function that will be executed if none is defined in the ebuild:
  
{{Note|Use esse método se você estiver inicializando sua BIOS, e se o o menu boot inicial do seu System Rescue CD initial estiver em azul claro. Se você for utilizar o método moderno, [[#Método Moderno (UEFI/GPT)|click aqui para saltar para o UEFI/GPT.]]}}
+
<pre>
 +
src_compile() {
 +
if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ] ; then
 +
emake || die "emake failed"
 +
fi
 +
}
 +
</pre>
  
===== Preparo =====
+
==== src_test ====
  
Primeiro, é uma boa idea certificar-se de que encontrou o hard disk correto para particioná-lo. Tente esse comando e verifique que  <code>/dev/sda</code> é o disco que você quer particionar:
+
<tt>src_test</tt> is an interesting function - by default, an end-user's Portage does not have tests enabled. But if a user has <tt>test</tt> in <tt>FEATURES</tt>, or <tt>EBUILD_FORCE_TEST</tt> is defined, then <tt>ebuild.sh</tt> will attempt to run a test suite for this ebuild, by executing <tt>make check</tt> or <tt>make test</tt> if these targets are defined in the Makefile; otherwise, no tests will execute. If your Makefile supports <tt>make check</tt> or <tt>make test</tt> but the test suite is broken, then specify <tt>RESTRICT="test"</tt> in your ebuild to disable the test suite.
  
<console>
+
==== src_install ====
# ##i##fdisk -l /dev/sda
+
  
Disk /dev/sda: 640.1 GB, 640135028736 bytes, 1250263728 sectors
+
<tt>src_install</tt> is used by the ebuild writer to install all to-be-installed files to the <tt>$D</tt> directory, which can be treated like an empty root filesystem, in that <tt>${D}/usr</tt> is the equivalent of the <tt>/usr</tt> directory, etc. When <tt>src_install</tt> runs, the Portage sandbox will be enabled, which will prevent any processes from creating or modifying files outside of the <tt>${D}</tt> filesystem tree, and a sandbox violation will occur (resulting in the termination of the ebuild) if any such sandbox violation should occur. Once <tt>src_install</tt> has perfomed all necessary steps to install all to-be-installed files to <tt>$D</tt>, Portage will take care of merging these files to the filesystem specified by the <tt>$ROOT</tt> environment variable, which defaults to <tt>/</tt> if not set. When Portage merges these files, it will also record information about the installed package to <tt>/var/db/pkg/(cat)/$P</tt>. Typically, a <tt>src_install</tt> function such as this is sufficient for ensuring that all to-be-installed files are installed to <tt>$D</tt>:
Units = sectors of 1 * 512 = 512 bytes
+
Sector size (logical/physical): 512 bytes / 512 bytes
+
I/O size (minimum/optimal): 512 bytes / 512 bytes
+
Disk label type: gpt
+
  
 +
<pre>
 +
src_install() {
 +
  make DESTDIR="$D" install
 +
}
 +
</pre>
  
#        Start          End    Size  Type            Name
+
=== pkg_* functions ===
1        2048  1250263694  596.2G  Linux filesyste Linux filesystem
+
</console>
+
  
Agora, é recomendado que você apague quaisquer tabelas de partição MBR ou GPT existente no disco, que poderiam confundir o BIOS do sistema no momento da inicialização. Fazemos isso utilizando <code>sgdisk</code>:
+
An ebuild's functions starting with <tt>pkg_*</tt> take a wider view of the package lifecycle, and may be executed very early or very late in the build or package installation process. They are also all executed even if installing a Portage binary package, so are the intended place for defining any global configuration changes that are also required during binary package installation, such as user and group creation. When these functions are executed, the <tt>$ROOT</tt> variable will be defined to point to the target root filesystem to which the package is to be (or has been) installed. All logic inside <tt>pkg_*</tt> functions must function properly even if <tt>$ROOT</tt> is something other than <tt>/</tt>.
{{fancywarning|Isso tornará quaisquer partições existentes inacessiveis! É formente lhe aconcelhado advetido realizar backup de qualquer dado crítico antes de prosseguir.}}
+
  
<console>
+
==== pkg_setup ====
# ##i##sgdisk --zap-all /dev/sda
+
  
Creating new GPT entries.
+
The <tt>pkg_setup</tt> function is unusual in that it runs prior to any <tt>src_*</tt> function, and also runs prior to any other <tt>pkg_*</tt> function that runs when a binary package is installed, so it provides a useful place for the ebuild writer to perform any sanity checks, global configuration changes to the system (such as user/group creation) or set any internal global variables that are used by the rest of the ebuild. Using this function for defining global variables that are needed in multiple other functions is a useful way of avoiding duplicate code. You should also look to <tt>pkg_setup</tt> as the ideal place to put any logic that would otherwise linger in the main body of the ebuild, which should be avoided at all costs as it will slow down dependency calculation by Portage. Also remember that Portage can build binary packages, and this function is a good place to execute any steps that are required to run both prior to building an ebuild, and prior to installing a package. Also consider using <tt>pkg_preinst</tt> and <tt>pkg_postinst</tt> for this purpose.
GPT data structures destroyed! You may now partition the disk using fdisk or
+
other utilities.
+
</console>
+
  
Essa saída també não é nada para se preocupar, desde que o comando ainda  foi bem sucedido:
+
==== pkg_pretend ====
  
<console>
+
The <tt>pkg_pretend</tt> function was added with EAPI 3, and it's the opinion of Daniel Robbins that the use of this function should be avoided. This function is especially unusual in that it is intended to be run ''during dependency calculation'', and is intended to provide a polite mechanism to inform the user that a particular ebuild will fail due to a known incompatibility, typically a kernel incompatibility. That way, the user can know during <tt>emerge --pretend</tt> that a merge will fail. While this is useful, extending the dependency engine using <tt>bash</tt> is a very low-performance means to perform these tests. Therefore, The Funtoo core team recommends against using <tt>pkg_pretend</tt>. An extensible dependency engine would be a more appropriate and high-performance way to provide identical functionality.
***************************************************************
+
Found invalid GPT and valid MBR; converting MBR to GPT format
+
in memory.  
+
***************************************************************
+
</console>
+
  
===== Particionamento =====
+
==== pkg_preinst ====
  
Agora usaremos <code>fdisk</code> para criar a tabela de partição MBR e as partições:
+
The <tt>pkg_preinst</tt> function is called by Portage, prior to merging the to-be-installed files to the target filesystem specified by <tt>$ROOT</tt> environment variable (which defaults to <tt>/</tt>.) Keep in mind that these to-be-installed files were either just compiled and installed to <tt>$D</tt> by <tt>src_install</tt>, or they were just extracted from a <tt>.tbz2</tt> binary package. The <tt>pkg_preinst</tt> function provides an ideal place to perform any "just before install" actions, such as user and group creation or other necessary steps to ensure that the package merges successfully. It also provides a potential place to perform any sanity checks related to installing the package to the target filesystem. If any sanity checks fail, calling <tt>die</tt> from this function will cause the package to not be installed to the target filesystem.
  
<console>
+
==== pkg_postinst ====
# ##i##fdisk /dev/sda
+
</console>
+
  
Dentro do <code>fdisk</code>, siga esses passos:
+
The <tt>pkg_postinst</tt> function is called by Portage prior to the package being installed to the target filesystem specified by <tt>$ROOT</tt>. This is a good place to perform any post-install configuration actions as well as print any informational messages for the user's benefit related to the package that was just installed.
  
'''Esvazie a tabela de partição''':
+
==== pkg_prerm ====
  
<console>
+
The <tt>pkg_prerm</tt> function is called by Portage before an ebuild is removed from the filesystem.
Command (m for help): ##i##o ↵
+
</console>
+
  
'''Crie a primeira Partição''' (boot):
+
==== pkg_postrm ====
  
<console>
+
The <tt>pkg_postrm</tt> function is called by Portage after an ebuild is removed from the filesystem.
Command (m for help): ##i##n ↵
+
Partition type (default p): ##i##↵
+
Partition number (1-4, default 1): ##i##↵
+
First sector: ##i##↵
+
Last sector: ##i##+128M ↵
+
</console>
+
  
'''Crie a segunda Partição''' (swap):
+
==== pkg_config ====
  
<console>
+
The <tt>pkg_config</tt> function is called by Portage when the user calls <tt>emerge --config</tt> for the ebuild. The current directory will be set to the current directory of the shell from where <tt>emerge --config</tt> is run.
Command (m for help): ##i##n ↵
+
=== Skipping over a function ===
Partition type (default p): ##i##↵
+
To skip over a function, create a function that does not do anything. The recommended way is to use bash no-op command:
Partition number (2-4, default 2): ##i##↵
+
<syntaxhighlight lang="bash">
First sector: ##i##↵
+
# Skip src_prepare.
Last sector: ##i##+2G ↵
+
src_prepare() { :; }
Command (m for help): ##i##t ↵
+
</syntaxhighlight>
Partition number (1,2, default 2): ##i## ↵
+
Hex code (type L to list all codes): ##i##82 ↵
+
</console>
+
  
'''Crie a partição root:'''
+
=== Extra pre_ and post_ functions ===
  
<console>
+
Modern versions of Portage also support functions identical to the above functions but with '''pre_''' and '''post_''' at the beginning of the function name. For example, <tt>post_src_configure</tt> will be executed after <tt>src_configure</tt> and before <tt>src_compile</tt>. These additional functions are supported by all EAPIs, provided that the parent function is supported by the EAPI in use. The initial current working directory should be identical to the initial current working directory of the parent function.
Command (m for help): ##i##n ↵
+
Partition type (default p): ##i##↵
+
Partition number (3,4, default 3): ##i##↵
+
First sector: ##i##↵
+
Last sector: ##i##↵
+
</console>
+
  
'''Verifique a tabela de partição:'''
+
=== Helper Functions ===
  
<console>
+
==== econf() ====
Command (m for help): ##i##p
+
  
Disk /dev/sda: 298.1 GiB, 320072933376 bytes, 625142448 sectors
+
econf() is part of ebuild.sh and is intended to be a wrapper to the <tt>configure</tt> command that is typically used in the <tt>src_configure()</tt> stage. It has a number of behaviors that are important for ebuild writers to understand. Once you understand what <tt>econf()</tt> does, you are free to use it in your ebuilds. Note that the behavior of <tt>econf()</tt> is generally safe for most autoconf-based source archives, but in some cases it may be necessary to avoid using <tt>econf()</tt> to avoid some of its default behaviors.
Units: sectors of 1 * 512 = 512 bytes
+
Sector size (logical/physical): 512 bytes / 512 bytes
+
I/O size (minimum/optimal): 512 bytes / 512 bytes
+
Disklabel type: dos
+
Disk identifier: 0x82abc9a6
+
  
Device    Boot    Start      End    Blocks  Id System
+
===== Automatically set prefix =====
/dev/sda1          2048    264191    131072  83 Linux
+
/dev/sda2        264192  4458495  2097152  82 Linux swap / Solaris
+
/dev/sda3        4458496 625142447 310341976  83 Linux
+
</console>
+
  
'''Grave a tabela de partição no disco:'''
+
<tt>--prefix=/usr</tt> will be passed to <tt>configure</tt> automatically, unless a <tt>--prefix</tt> argument was specified to <tt>econf()</tt>, in which case, that <tt>--prefix</tt> setting will be used instead.
  
<console>
+
===== Automatically set libdir =====
Command (m for help): ##i##w
+
</console>
+
  
Sua nova tabela de partição MBR será agora gravada no seu disco.
+
If the <tt>ABI</tt> variable is set (typically done in the profile), then <tt>econf()</tt> will look for a variable named <tt>LIBDIR_$ABI</tt> (ie. <tt>LIBDIR_amd64</tt>). If this variable is set, the value of this variable will be used to set <tt>libdir</tt> to the value of <tt>{prefix}/LIBDIR_$ABI</tt>.
  
{{Note|Você finalizou o particionamento! Agora, pule para [[#Criando os filesystems|Criando os filesystems]].}}
+
===== Automatically set CHOST and CTARGET =====
  
==== Método Moderno (UEFI/GPT)  ====
+
The <tt>--host=$CHOST</tt> argument will be passed to <tt>configure</tt>. <tt>$CHOST</tt> is defined in the system profile. In addition, the <tt>--target=$CTARGET</tt> argument will be passed to <tt>configure</tt> if <tt>$CTARGET</tt> is defined. This is not normally required but is done to make Portage more capable of cross-compiling the ebuild. However, this functionality is not a guarantee that your ebuild will successfully cross-compile, as other changes to the ebuild may be necessary.
  
{{Note|Use esse método se você estiver inicializando usando o UEFI, e se o menu de boot do seu System Rescue CD initial boot for preto e branco. Se for azul claro, esse método não funcionará.}}
+
===== Disable Dependency Tracking (EAPI 4) =====
  
Utilize o comando <tt>gdisk</tt> para criar uma tabela de partição GPT como a seguir. Adapte tamanhos conforme necessário, embora esse padrões funcionarão para a maioria dos  suários. Inicie o <code>gdisk</code>:
+
In EAPI 4, the <tt>--disable-dependency-tracking</tt> argument will be passed to <tt>configure</tt> in order to optimize the performance of the configuration process. This option should have no impact other than on the performance of the <tt>configure</tt> script.
  
<console>
+
===== List of arguments =====
# ##i##gdisk
+
</console>
+
  
Dentro do <tt>gdisk</tt>, Siga esses passos:
+
The following arguments are passed to <tt>configure</tt> and are all overrideable by the user by passing similar options to <tt>econf()</tt>:
  
'''Crie uma uma nova tabela de partição vazia''' (Isso ''apagará'' todos os dados no seu disco quando salvo):
+
* <tt>--prefix=/usr</tt>
 +
* <tt>--libdir={prefix}/LIBDIR_$ABI</tt>
 +
* <tt>--host=${CHOST}</tt>
 +
* if CTARGET is defined, then <tt>--target=${CTARGET}</tt>
 +
* <tt>--mandir=/usr/share/man</tt>
 +
* <tt>--infodir=/usr/share/info</tt>
 +
* <tt>--datadir=/usr/share</tt>
 +
* <tt>--sysconfdir=/etc</tt>
 +
* <tt>--localstatedir=/var/lib</tt>
 +
* if EAPI 4+, then <tt>--disable-dependency-tracking</tt>
  
<console>
+
[[Category:Internals]]
Command: ##i##o ↵
+
[[Category:Portage]]
This option deletes all partitions and creates a new protective MBR.
+
[[Category:Official Documentation]]
Proceed? (Y/N): ##i##y ↵
+
</console>
+
 
+
'''Crie a 1ª Partiçaõ''' (boot):
+
 
+
<console>
+
Command: ##i##n ↵
+
Partition Number: ##i##1 ↵
+
First sector: ##i##↵
+
Last sector: ##i##+500M ↵
+
Hex Code: ##i##↵
+
</console>
+
 
+
'''Crie a 2ª Partição''' (swap):
+
 
+
<console>
+
Command: ##i##n ↵
+
Partition Number: ##i##2 ↵
+
First sector: ##i##↵
+
Last sector: ##i##+4G ↵
+
Hex Code: ##i##8200 ↵
+
</console>
+
 
+
'''Create 3ª Partição''' (root):
+
 
+
<console>
+
Command: ##i##n ↵
+
Partition Number: ##i##3 ↵
+
First sector: ##i##↵
+
Last sector: ##i##↵##!i## (for rest of disk)
+
Hex Code: ##i##↵
+
</console>
+
 
+
Ao longo do caminho, você pode digitar "<tt>p</tt>" e apertar Enter para visualizar a tabela de partição atual. Se você cometar algum engano, você pode digitar "<tt>d</tt>" tuma partição existente que você criou. Quando estiver satisfeito com sua definição de partição, digite "<tt>w</tt>" para gravar sua configuração no disco:
+
 
+
'''Gravar a Tabela de Partição no Disco''':
+
 
+
<console>
+
Command: ##i##w ↵
+
Do you want to proceed? (Y/N): ##i##Y ↵
+
</console>
+
 
+
A tabela de partição será agora gravada em disco e o <tt>gdisk</tt> será fechado.
+
 
+
Agora, suas partições GPT/GUID foram criadas, e será exibido os seguintes ''dispositivos de bloco''  (''block devices'') no Linux:
+
 
+
* <tt>/dev/sda1</tt>, which will be used to hold the <tt>/boot</tt> filesystem,
+
* <tt>/dev/sda2</tt>, which will be used for swap space, and
+
* <tt>/dev/sda3</tt>, which will hold your root filesystem.
+
 
+
==== Criando os filesystems ====
+
 
+
{{Note|Essa seção cobre tanto instalação pelo  BIOS ''quanto pelo'' UEFI. Não pule esse passo!}}
+
 
+
Antes que a suas partições recém-criadas possam ser utilizada, os dispositivos de bloco precisam ser inicializados com os '''metadados'' sistema de arquivos (filesystem ''metadata''). Esse processi é conhecido como ''criar um sistema de arquivo'' (''creating a filesystem'') nos dispositivos de bloco. Depois que os filesystems são criados nos dispositivos de bloco, eles podem ser montados e utilizados para armazenar arquivos.
+
 
+
Vamos deixar isso de forma simples. Você vai utilizar partições MBR a moda antiga? Se sim, vamos criar um sistema de arquivo ext2 em /dev/sda1:
+
 
+
<console>
+
# ##i##mkfs.ext2 /dev/sda1
+
</console>
+
 
+
Se for utilizar partições GPT modernas para o UEFI, você precisará criar um sistema de arquivos vfat no /dev/sda1, por isso é o que o UEFI é capaz de ler:
+
 
+
<console>
+
# ##i##mkfs.vfat -F 32 /dev/sda1
+
</console>
+
 
+
Agora, vamos criar uma partição swap. Essa partição será criada para ser utilizada como memoria virtual com base no disco (disk-based virtual memory) para o seu sistema Funtoo Linux.
+
 
+
Você criará um sistema de arquivos na sia partição swap, desde não seja utilizada para armazenar arquivos. Mas é necessário inicializá-la utilizando o comando <code>mkswap</code> command. Depois vamos executar o comando <code>swapon</code> para tornar o seu recém inicializado espaço swap imediadamente ativo  dentro do ambiente live CD, nesse caso isso é necessário durante o resto do processo de instalação:
+
 
+
<console>
+
# ##i##mkswap /dev/sda2
+
# ##i##swapon /dev/sda2
+
</console>
+
 
+
Agora, precisamos criar um sistema de arquivos root. É alí aonde o Funtoo Linux vai morar. Geralmente recomendamos sistemas de arquivos root ext4 ou XFS. Se não estiver certo, escola o  ext4. Aqui está como criar um sistema de arquivos root ext4:
+
 
+
<console>
+
# ##i##mkfs.ext4 /dev/sda3
+
</console>
+
 
+
...e aqui está como criar um sistema de arquivos root XFS, se você escolher utilizar o XFS:
+
 
+
<console>
+
# ##i##mkfs.xfs /dev/sda3
+
</console>
+
 
+
Seus sistemas de arquivos (e o swap) foram todos inicializados, então dessa forma podem ser montados (anexados á sua hierarquia de diretório existente) e utilizado para armazenar arquivos. Estamos prontos para instalar o Funtoo Linux nesses sistemas de arquivos novinhos em folha.
+
 
+
{{fancywarning|1=
+
Quando implantar um host OpenVZ, por favor utilize exclusivamente o ext4. A equipe de desenvolvimento paralelos testa extensi extensivamente com o ext4, e versões mais modernas do  <code>openvz-rhel6-stable</code> ''não'' são compatíveis com o XFS, e você pode experimentar kernel bugs.
+
}}
+
 
+
==== Montando os filesystems ====
+
 
+
Monte os recem-criados filesystems como a seguir, criando <code>/mnt/funtoo</code> como ponto de montagem da instalação:
+
 
+
<console>
+
# ##i##mkdir /mnt/funtoo
+
# ##i##mount /dev/sda3 /mnt/funtoo
+
# ##i##mkdir /mnt/funtoo/boot
+
# ##i##mount /dev/sda1 /mnt/funtoo/boot
+
</console>
+
 
+
Optionally, if you have a separate filesystem for <code>/home</code> or anything else:
+
 
+
<console>
+
# ##i##mkdir /mnt/funtoo/home
+
# ##i##mount /dev/sda4 /mnt/funtoo/home
+
</console>
+
 
+
If you have <code>/tmp</code> or <code>/var/tmp</code> on a separate filesystem, be sure to change the permissions of the mount point to be globally-writeable after mounting, as follows:
+
 
+
<console>
+
# ##i##chmod 1777 /mnt/funtoo/tmp
+
</console>
+

Revision as of 10:19, February 7, 2015

Ebuild Functions

Ebuilds provide the ability to define various shell functions that are used to specify various actions relating to building and installing a source or binary package on a user's system. When an ebuild is emerged, the following functions are called, in order:

  • pkg_setup - variable intialization and sanity checks
  • src_unpack
  • src_prepare
  • src_configure
  • src_compile
  • src_install

At this point, the files are ready to be "merged" into the live filesystem. This is when they are copied from the temporary build directory into /usr, etc. At this point, the following functions are executed:

  • pkg_preinst
  • (files are merged)
  • pkg_postinst

src_* functions

Ebuild functions starting with src_ are all related to creating the ebuild or package from source code/artifacts, and are defined below:

src_unpack

src_unpack is intended to be used to unpack the source code/artifacts that will be used by the other src_* functions. With EAPI 1 and earlier, it is also used for patching/modifying the source artifacts to prepare them for building, but with EAPI 2 or later the src_prepare function should be used for this instead. When src_unpack starts, the current working directory is set to $WORKDIR, which is the directory within which all source code/artifacts should be expanded. Note that the variable $A is set to the names of all the unique source files/artifacts specified in SRC_URI, and they will all be available in $DISTDIR by the time src_unpack starts. Also note that if no src_unpack function is specified, ebuild.sh will execute the following function for src_unpack by default:

src_unpack() {
  unpack ${A}
}

src_prepare

EAPI 2 and above support the src_prepare function, which is intended to be used for applying patches or making other modifications to the source code. When src_prepare starts, the current working directory is set to $S.

src_configure

EAPI 2 and above support the src_configure function, which is used to configure the source code prior to compilation. With EAPI 2 and above, the following default src_configure is defined if none is specified:

src_configure() {
	if [[ -x ${ECONF_SOURCE:-.}/configure ]] ; then
		econf
	fi
}

src_compile

This function defines the steps necessary to compile source code. With EAPI 1 and earlier, this function is also used to configure the source code prior to compilation. However, starting with EAPI 2, the src_configure function must be used for configuration steps instead of bundling them inside src_compile. In addition, starting with EAPI 2, there is now a default src_compile function that will be executed if none is defined in the ebuild:

src_compile() {
	if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ] ; then
		emake || die "emake failed"
	fi
}

src_test

src_test is an interesting function - by default, an end-user's Portage does not have tests enabled. But if a user has test in FEATURES, or EBUILD_FORCE_TEST is defined, then ebuild.sh will attempt to run a test suite for this ebuild, by executing make check or make test if these targets are defined in the Makefile; otherwise, no tests will execute. If your Makefile supports make check or make test but the test suite is broken, then specify RESTRICT="test" in your ebuild to disable the test suite.

src_install

src_install is used by the ebuild writer to install all to-be-installed files to the $D directory, which can be treated like an empty root filesystem, in that ${D}/usr is the equivalent of the /usr directory, etc. When src_install runs, the Portage sandbox will be enabled, which will prevent any processes from creating or modifying files outside of the ${D} filesystem tree, and a sandbox violation will occur (resulting in the termination of the ebuild) if any such sandbox violation should occur. Once src_install has perfomed all necessary steps to install all to-be-installed files to $D, Portage will take care of merging these files to the filesystem specified by the $ROOT environment variable, which defaults to / if not set. When Portage merges these files, it will also record information about the installed package to /var/db/pkg/(cat)/$P. Typically, a src_install function such as this is sufficient for ensuring that all to-be-installed files are installed to $D:

src_install() {
  make DESTDIR="$D" install
}

pkg_* functions

An ebuild's functions starting with pkg_* take a wider view of the package lifecycle, and may be executed very early or very late in the build or package installation process. They are also all executed even if installing a Portage binary package, so are the intended place for defining any global configuration changes that are also required during binary package installation, such as user and group creation. When these functions are executed, the $ROOT variable will be defined to point to the target root filesystem to which the package is to be (or has been) installed. All logic inside pkg_* functions must function properly even if $ROOT is something other than /.

pkg_setup

The pkg_setup function is unusual in that it runs prior to any src_* function, and also runs prior to any other pkg_* function that runs when a binary package is installed, so it provides a useful place for the ebuild writer to perform any sanity checks, global configuration changes to the system (such as user/group creation) or set any internal global variables that are used by the rest of the ebuild. Using this function for defining global variables that are needed in multiple other functions is a useful way of avoiding duplicate code. You should also look to pkg_setup as the ideal place to put any logic that would otherwise linger in the main body of the ebuild, which should be avoided at all costs as it will slow down dependency calculation by Portage. Also remember that Portage can build binary packages, and this function is a good place to execute any steps that are required to run both prior to building an ebuild, and prior to installing a package. Also consider using pkg_preinst and pkg_postinst for this purpose.

pkg_pretend

The pkg_pretend function was added with EAPI 3, and it's the opinion of Daniel Robbins that the use of this function should be avoided. This function is especially unusual in that it is intended to be run during dependency calculation, and is intended to provide a polite mechanism to inform the user that a particular ebuild will fail due to a known incompatibility, typically a kernel incompatibility. That way, the user can know during emerge --pretend that a merge will fail. While this is useful, extending the dependency engine using bash is a very low-performance means to perform these tests. Therefore, The Funtoo core team recommends against using pkg_pretend. An extensible dependency engine would be a more appropriate and high-performance way to provide identical functionality.

pkg_preinst

The pkg_preinst function is called by Portage, prior to merging the to-be-installed files to the target filesystem specified by $ROOT environment variable (which defaults to /.) Keep in mind that these to-be-installed files were either just compiled and installed to $D by src_install, or they were just extracted from a .tbz2 binary package. The pkg_preinst function provides an ideal place to perform any "just before install" actions, such as user and group creation or other necessary steps to ensure that the package merges successfully. It also provides a potential place to perform any sanity checks related to installing the package to the target filesystem. If any sanity checks fail, calling die from this function will cause the package to not be installed to the target filesystem.

pkg_postinst

The pkg_postinst function is called by Portage prior to the package being installed to the target filesystem specified by $ROOT. This is a good place to perform any post-install configuration actions as well as print any informational messages for the user's benefit related to the package that was just installed.

pkg_prerm

The pkg_prerm function is called by Portage before an ebuild is removed from the filesystem.

pkg_postrm

The pkg_postrm function is called by Portage after an ebuild is removed from the filesystem.

pkg_config

The pkg_config function is called by Portage when the user calls emerge --config for the ebuild. The current directory will be set to the current directory of the shell from where emerge --config is run.

Skipping over a function

To skip over a function, create a function that does not do anything. The recommended way is to use bash no-op command:

# Skip src_prepare.
src_prepare() { :; }

Extra pre_ and post_ functions

Modern versions of Portage also support functions identical to the above functions but with pre_ and post_ at the beginning of the function name. For example, post_src_configure will be executed after src_configure and before src_compile. These additional functions are supported by all EAPIs, provided that the parent function is supported by the EAPI in use. The initial current working directory should be identical to the initial current working directory of the parent function.

Helper Functions

econf()

econf() is part of ebuild.sh and is intended to be a wrapper to the configure command that is typically used in the src_configure() stage. It has a number of behaviors that are important for ebuild writers to understand. Once you understand what econf() does, you are free to use it in your ebuilds. Note that the behavior of econf() is generally safe for most autoconf-based source archives, but in some cases it may be necessary to avoid using econf() to avoid some of its default behaviors.

Automatically set prefix

--prefix=/usr will be passed to configure automatically, unless a --prefix argument was specified to econf(), in which case, that --prefix setting will be used instead.

Automatically set libdir

If the ABI variable is set (typically done in the profile), then econf() will look for a variable named LIBDIR_$ABI (ie. LIBDIR_amd64). If this variable is set, the value of this variable will be used to set libdir to the value of {prefix}/LIBDIR_$ABI.

Automatically set CHOST and CTARGET

The --host=$CHOST argument will be passed to configure. $CHOST is defined in the system profile. In addition, the --target=$CTARGET argument will be passed to configure if $CTARGET is defined. This is not normally required but is done to make Portage more capable of cross-compiling the ebuild. However, this functionality is not a guarantee that your ebuild will successfully cross-compile, as other changes to the ebuild may be necessary.

Disable Dependency Tracking (EAPI 4)

In EAPI 4, the --disable-dependency-tracking argument will be passed to configure in order to optimize the performance of the configuration process. This option should have no impact other than on the performance of the configure script.

List of arguments

The following arguments are passed to configure and are all overrideable by the user by passing similar options to econf():

  • --prefix=/usr
  • --libdir={prefix}/LIBDIR_$ABI
  • --host=${CHOST}
  • if CTARGET is defined, then --target=${CTARGET}
  • --mandir=/usr/share/man
  • --infodir=/usr/share/info
  • --datadir=/usr/share
  • --sysconfdir=/etc
  • --localstatedir=/var/lib
  • if EAPI 4+, then --disable-dependency-tracking