|
|
Line 1: |
Line 1: |
| = Prefácio = | | ==== Zugriff auf das Netzwerk ==== |
| | |
| == Como o Metro Funciona == | |
| | |
| Você pode estar se perguntando como o [[Metro]] cria seu primeiro stage tarball. Como você pode ter imaginado, [[Metro]] não pode criar um stage tarball. Para construi um novo stage tarball, [[Metro]] deve utilizar um já existente, antigo stage tarball chamado de uma "seed" stage. Essa semente "semente" stage tipicamente é utilizado com o ''ambiente build'' para a criação do stage que queremos.
| |
| | |
| [[Metro]] pode utilizar dois tipos de semente stages. Tradicionalmente, [[Metro]] tem utilizado um stage3 como uma semente stage. Esse stage3 é então utilizado para construir um novo stage1, que em troca é utlilizado para construir um novo stage2, e então um novo stage3. Esse é geralmente o jeito mais confiável de construir [[Gentoo_Linux/pt-br|Gentoo Linux]] ou [[Funtoo Linux]], entao essa é a recomendação recomendada.
| |
| {{fancyimportant|'''Depois de portar o metro builds para o perfil do Funtoo, os stages do Gentoo não são mais fornecidos'''!}}
| |
| | |
| == Sementes e Build Isolation == | |
| | |
| Um outro conceito importante a mencionar aqui é algo chamando de ''build isolation''. Por que o [[Metro]] cria um ambiente build isolado, e o ambiente build é explicitamente definido utilizando entidades existentes, tangíveis -- uma semente stage e um portage snapshot -- você obterá resultados consistentes, repetíveis. Em outras palavras, a mesma semente stage, portage snapshot e instrções build gerarão resultados identico, mesmo se você desempenhar o um mês mais tarde em algum workstation de outro pessoa.
| |
| | |
| == Local Build ==
| |
| | |
| Digamos que você queira construir um novo tarball stage3 <tt>pentium4</tt>. O módo recomendado de se fazer isso seria apanhar um tarball stage3 <tt>pentium4</tt> existente como sua semente stage3 stage. Será dito ao [[Metro]] utilizar o stage3 <tt>pentium4</tt> existente para construir um novo stage1 para o mesmo <tt>pentium4</tt>. Para esse process, o stage3 para o <tt>pentium4</tt> genérico forneceria o ''ambiente build'' para a criação de nosso novo stage1. Então, o novo stage1 serviria como o ambiente build (build environment) para a criação do novo stage2 <tt>pentium4</tt>. E o novo stage2 para <tt>pentium4</tt> serviria como o ambiente build para a criação do novo stage3 para <tt>pentium4</tt>.
| |
| | |
| Na terminologia [[Metro]] isso é chamado de um '''local build''', que significa que um stage3 de uma dada arquitetura é utilizada para semear um build novo em folha da mesma arquitetura. Incidentalmente esse será o primeiro exercício que vamos realizar nesse tutorial.
| |
| | |
| Uma semana depois, você pode querer construir um tarball stage3 para <tt>pentium4</tt> novo em folha. Ao invés de iniciar a partir do stage3 para <tt>pentium4</tt> original de novo, você provavelmente configuraria o [[Metro]] para utilizar o built stage3 para <tt>pentium4</tt> mais recente construído como a semente. [[Metro]] possui funcionalidade built-in para tornar isso fácil, permitindo facilmente encontrar e rastrear a semente stage3 mais recente disponível.
| |
| | |
| == Build Remoto ==
| |
| | |
| [[Metro]] pode também desempenhar '''build remoto (remote build)''', onde um stage3 de uma arquitetura diferente, mas compatível binariamente, é utilizado como uma semente para construir um stage3 de arquitetura diferente. Consequencialidade, no segundo exercício que vamos realizar nesse tutorial será construir um tarball stage3 para <tt>core2 32bit</tt> a partir do tarball stage3 do <tt>pentium4</tt> que acabamos de construir.
| |
| | |
| TODO: adicione ressalvas a respeito de quais arquiteturas podem ser semeadas e quais não podem (talvez um table?)
| |
| | |
| == Build Adaptado ==
| |
| | |
| Por ultimo, também é válido tanto <tt>local</tt> e <tt>builds remotos</tt>, [[Metro]] pode ser configurado para adicionar e/ou remover pacotes individuais ao ultimo tarball.
| |
| Digamos que você não consiga viver sem <tt>app-misc/screen</tt>, no final desse tutorial, mostraremos como obter o seu stage3 adaptado para incluí-lo.
| |
| | |
| == Instalar o Metro ==
| |
| | |
| '''O método recomendado e que possui suporte''' é utilizar o repositório Git do [[Metro]].
| |
| | |
| Asegure-se de que {{Package|dev-vcs/git}} e {{Package|dev-python/boto}} (opcional; exigido para suporte EC2) sejam estalados no seu sistema:
| |
| | |
| <console>
| |
| # ##i##emerge dev-vcs/git
| |
| # ##i##emerge dev-python/boto
| |
| </console>
| |
| | |
| Depois, clone o master git repository como a seguir:
| |
| | |
| <console>
| |
| # ##i##cd /root
| |
| # ##i##git clone git://github.com/funtoo/metro.git
| |
| # ##i##cp /root/metro/metro.conf ~/.metro
| |
| </console>
| |
| | |
| Agora você terá o diretório chamado <tt>/root/metro</tt> que contem todo o código fonte do [[Metro]].
| |
| | |
| O Metro agora está instalado. É hora de personalizá-lo para o seu sistema local.
| |
| | |
| = Configurando o Metro =
| |
| | |
| {{Note|Metro não é atualmente capaz de construir stages do Gentoo. Veja {{Bug|FL-901}}.}}
| |
| | |
| [[User:Drobbins|Daniel Robbins]] mantem o [[Metro]], então ele vem pré-configurado para construir com sucesso os lançamentos do [[Funtoo Linux]]. Antes de ler mais adiante, você pode querer personalizar algumas configurações básicas como o o número de de jobs simultâneos para se encaixar as compatibilidades do seu hardware ou o diretório para utilizar arquivos stage produzidos. Isso é excelente ao editar <tt>~/.metro</tt> a qual é o arquivo de configuração [[Metro]]'s master.
| |
| | |
| Por favor, note que o <code>path/install</code> deve apontar para aonde o metro foi instalado. Aponte <code>path/distfiles</code> para aonde seus distfiles residem. Defina também <code>path/mirror/owner</code> e <code>path/mirror/group</code> para o proprietário e grupo de todos os arquivos que serão escritos para construir o diretório do repositório, que por padrão (como por arquivo de configuração) está em <code>/home/mirror/funtoo</code>. O diretório cache normalmente reside dentro do diretório temporário -- Isso pode ser modificado como desejado. O diretório cache pode terminar contendo muitos pacotes .tbz2 em cache, e comer um monte de armazenamento (storage). Você pode de repente querer colocar o diretório temporário em armazenamento mais rápido, para tempos de compilação mais rápidas, e colocar o diretório cache em armazenamento mais lento, porém mais abundante.
| |
| | |
| {{file|name=.metro|desc=Metro configuration|body=
| |
| # Main metro configuration file - these settings need to be tailored to your install:
| |
| | |
| [section path]
| |
| install: /root/metro
| |
| tmp: /var/tmp/metro
| |
| cache: $[path/tmp]/cache
| |
| distfiles: /var/src/distfiles
| |
| work: $[path/tmp]/work/$[target/build]/$[target/name]
| |
| | |
| [section path/mirror]
| |
| | |
| : /home/mirror/funtoo
| |
| owner: root
| |
| group: repomgr
| |
| dirmode: 775
| |
| | |
| [section portage]
| |
| | |
| MAKEOPTS: auto
| |
| | |
| [section emerge]
| |
| | |
| options: --jobs=4 --load-average=4 --keep-going=n
| |
| | |
| # This line should not be modified:
| |
| [collect $[path/install]/etc/master.conf]
| |
| }}
| |
| | |
| == Arch e Subarch ==
| |
| | |
| No exemplo a seguir estamos gerando um stage 3 para pentium4 compilado para a compatibilidade binária x86-32bit. Pentium4 é uma subarch da arquitetura x86-32bit. Uma vez que você tenha o metro instalado, você pode encontrar uma lista completa de cada subarch em seu diretório <tt>/root/metro/subarch</tt>; cada arquitetura terá a extensão de arquivo .spec
| |
| Example:
| |
| <console>
| |
| ###i## ls /root/metro/subarch
| |
| # ls subarch/
| |
| amd64-bulldozer-pure64.spec armv7a.spec core-avx-i.spec i686.spec pentium.spec
| |
| amd64-bulldozer.spec armv7a_hardfp.spec core2_32.spec k6-2.spec pentium2.spec
| |
| amd64-k10-pure64.spec athlon-4.spec core2_64-pure64.spec k6-3.spec pentium3.spec
| |
| amd64-k10.spec athlon-mp.spec core2_64.spec k6.spec pentium4.spec
| |
| amd64-k8+sse3.spec athlon-tbird.spec corei7-pure64.spec native_32.spec pentiumpro.spec
| |
| amd64-k8+sse3_32.spec athlon-xp.spec corei7.spec native_64.spec prescott.spec
| |
| amd64-k8-pure64.spec athlon.spec generic_32.spec niagara.spec ultrasparc.spec
| |
| amd64-k8.spec atom_32.spec generic_64-pure64.spec niagara2.spec ultrasparc3.spec
| |
| amd64-k8_32.spec atom_64-pure64.spec generic_64.spec nocona.spec xen-pentium4+sse3.spec
| |
| armv5te.spec atom_64.spec generic_sparcv9.spec opteron_64.spec xen-pentium4+sse3_64.spec
| |
| armv6j.spec btver1.spec geode.spec pentium-m.spec
| |
| armv6j_hardfp.spec btver1_64.spec i486.spec pentium-mmx.spec
| |
| </console>
| |
| | |
| = Primeiro build dos stages (build local) =
| |
| | |
| Para iniciar isso tudo, precisamos iniciar (bootstrap) o processo ao baixar uma semente stage3 inicial para utilizá-la para a construção e colocar em seu seu local adequado <tt>/home/mirror/funtoo</tt>, então assim o [[Metro]] pode encontrá-lo. Também vamos precisar gerar algum "controle" especial; arquivos em <tt>/home/mirror/funtoo</tt>, que permitirão ao [[Metro]] entender como é para ele proceder.
| |
| | |
| == 1º Passo: Definir o repositório do pentium4 (build local) ==
| |
| | |
| Supondo que estamos seguindo os passos básicos delineados na seção anterior, e construindo um unstable funtoo (<tt>funtoo-current</tt>) feito para o <tt>pentium4</tt>, utilizando um stage3 <tt>pentium4</tt> genérico como uma semente stage, então aqui o primeiro conjunto de passos que realizaríamos:
| |
| | |
| <console>
| |
| # ##i##install -d /home/mirror/funtoo/funtoo-current/x86-32bit/pentium4
| |
| # ##i##install -d /home/mirror/funtoo/funtoo-current/snapshots
| |
| # ##i##cd /home/metro/mirror/funtoo/funtoo-current/x86-32bit/pentium4
| |
| # ##i##install -d 2011-12-13
| |
| # ##i##cd 2011-12-13
| |
| # ##i##wget -c http://ftp.osuosl.org/pub/funtoo/funtoo-current/x86-32bit/pentium4/2011-12-13/stage3-pentium4-funtoo-current-2011-12-13.tar.xz
| |
| # ##i##cd ..
| |
| # ##i##install -d .control/version
| |
| # ##i##echo "2011-12-13" > .control/version/stage3
| |
| # ##i##install -d .control/strategy
| |
| # ##i##echo local > .control/strategy/build
| |
| # ##i##echo stage3 > .control/strategy/seed
| |
| </console>
| |
| | |
| OK, vamos rever os passos acima. Primeiro, geramos o diretório <tt>/home/mirror/funtoo/funtoo-current/x86-32bit/pentium4</tt>, o qual é onde o Metro esperará encontrar o builds do pentuim4 unstable <tt>funtoo-current</tt> -- ele é configurado para procurar aqui por padrão. Então geramos um diretório com nome especial para abrigar nossa semente stage3 x86. Novamente, por padrão, Metro espera que o diretório seja nomeado desse jeito. Entramos nesse diretório, e baixamos nossa semente stage3 x86 a partir do funtoo.org. Note que o selo da versão <tt>2010-12-24</tt> combina. Certifique-se de que o nome do seu diretório combina com o nome do stage3 também. Tudo tem sido definido para combinar com o layout do sistema de arquivos padrão do Metro.
| |
| | |
| Próximo passo, voltamos ao diretório <tt>/home/mirror/metro/funtoo-current/x86-32bit/pentium4</tt>, e dentro disso,geramos um diretório <tt>.control</tt>. Esse diretório e seus subdiretórios contem arquivos especiais que o Metro se refere para determinar certos aspectos de seu comportamento. O arquivo <tt>.control/version/stage3</tt> é utilizado pelo Metro para rastrear o stage3 maus recente construído para esse build e subacrh particular. O Metro automaticamente atualizará esse arquivo com uma nova versão de selo depois que ele construir com sucesso um novo stage3. Mas por que o Metro na verdão não ''construiu'' esse stage3, precisamos configurar o arquivo <tt>.control/version/stage3</tt> manualmente. Isso vai permitir que o Metro encontre nosso stage3 baixado quando nos configuramos nosso build para pentium4 para utilizá-lo como uma semente. Note também que o Metro gerará um arquivo <tt>.control/version/stage1</tt> similar depois que ele construir com sucesso um stage1 do funtoo-current para pentium4.
| |
| | |
| Nós também configuramos os arquivos <tt>.control/strategy/build</tt> e <tt>.control/strategy/seed</tt> com valores de <tt>local</tt> e <tt>stage3</tt> respectivamente. Esses arquivos definem a estratégia de construção que o Metro utilizará quando construirmos os stages do funtoo-current para pentium4. Com uma estratégia de build do <tt>local</tt>, Metro dará origem a sua semente stage a partir do funtoo-current pentium4, o diretório atual (current). E com a estratégia da semente <tt>stage3</tt>, Metro utilizará um stage3 como uma semente, e utilizar essa semente para construir um novo stage1, stage2 e stage3.
| |
| | |
| == 2º Passo: Construindo stages para o pentium4 ==
| |
| | |
| A propósito, se tudo o que você queria fazer nesse ponto era construir um novo stage1/2/3 do funtoo-current para pentium4 (mais openvz e templates vserver). Você iniciaria o processo ao digitar:
| |
| | |
| <console>
| |
| # ##i##cd /root/metro
| |
| # ##i##scripts/ezbuild.sh funtoo-current pentium4
| |
| </console>
| |
| | |
| Se você possui uma máquina lenta, ela poderia levar várias horas para completar por que vários componentes "heavy" como o gcc ou glibc tem que ser recompilado em cada stage. Uma vez um stage tem sido completado com sucesso, ele é colocado no subdiretório <tt>"${METRO_MIRROR}/funtoo-current/x32-bit/pentium4/YYYY-MM-DD"</tt>, onde <tt>YYYY-MM-DD</tt> ié a data de hoje no momento que o script <tt>ezbuild.sh</tt> foi iniciado ou a data que você inseriu no comando ezscript.sh.
| |
| | |
| = Building for another binary compatible architecture (remote build) =
| |
| | |
| As written above, [[Metro]] is able to perform '''remote build''' building different architecture stage3 from a binary compatible seeding stage3 (e.g. using a pentium4 stage3 to seed a <tt>Intel Core2 32bits</tt> stage3).
| |
| | |
| In the Metro terminology this is called a '''remote build''' (a stage 3 of a different, but binary compatible, architecture is used as a seed).
| |
| What's not compatible? You can't use a <tt>Sparc</tt> architecture to generate an <tt>x86</tt> or <tt>ARM</tt> based stage and vice-versa. If you use a 32bit stage then you don't want to seed a 64bit build from it. Be sure that you are using a stage from the same architecture that you are trying to seed. Check [http://ftp.osuosl.org/pub/funtoo/funtoo-current/ Funtoo-current FTP Mirror] for a stage that is from the same Architecture that you will be building.
| |
| | |
| {{Note|Often, one build (ie. funtoo-current) can be used as a seed for another build such as funtoo-stable. However, hardened builds require hardened stages as seeds in order for the build to complete successfully.}}
| |
| | |
| == Step 1: Set up Core_2 32bit repository ==
| |
| | |
| In this example, we're going to use this pentium4 funtoo-current stage3 to seed a new Core_2 32bit funtoo-current build. To get that done, we need to set up the pentium4 build directory as follows:
| |
| | |
| <console>
| |
| # ##i## cd /home/mirror/funtoo/funtoo-current/x86-32bit
| |
| # ##i##install -d core2_32
| |
| # ##i##cd core2_32
| |
| # ##i##install -d .control/strategy
| |
| # ##i##echo remote > .control/strategy/build
| |
| # ##i##echo stage3 > .control/strategy/seed
| |
| # ##i##install -d .control/remote
| |
| # ##i##echo funtoo-current > .control/remote/build
| |
| # ##i##echo x86-32bit > .control/remote/arch_desc
| |
| # ##i##echo pentium4 > .control/remote/subarch
| |
| </console>
| |
| | |
| The steps we follow are similar to those we performed for a ''local build'' to set up our pentium4 directory for local build. However, note the differences. We didn't download a stage, because we are going to use the pentium4 stage to build a new Core_2 32bit stage. We also didn't create the <tt>.control/version/stage{1,3}</tt> files because Metro will create them for us after it successfully builds a new stage1 and stage3. We are still using a <tt>stage3</tt> seed strategy, but we've set the build strategy to <tt>remote</tt>, which means that we're going to use a seed stage that's not from this particular subdirectory. Where are we going to get it from? The <tt>.control/remote</tt> directory contains this information, and lets Metro know that it should look for its seed stage3 in the <tt>/home/mirror/funtoo/funtoo-current/x86-32bit/pentium4</tt> directory. Which one will it grab? You guessed it -- the most recently built ''stage3'' (since our seed strategy was set to <tt>stage3</tt>) that has the version stamp of <tt>2010-12-24</tt>, as recorded in <tt>/home/mirror/funtoo-current/x86-32bit/pentium4/.control/version/stage</tt>. Now you can see how all those control files come together to direct Metro to do the right thing.
| |
| | |
| {{Note|<code>arch_desc</code> should be set to one of: <code>x86-32bit</code>, <code>x86-64bit</code> or <code>pure64</code> for PC-compatible systems. You must use a 32-bit build as a seed for other 32-bit builds, and a 64-bit build as a seed for other 64-bit builds.}}
| |
| | |
| == Step 2: Building the Core_2 32bit stages ==
| |
| | |
| Now, you could start building your new Core_2 32bit stage1/2/3 (plus openvz and vserver templates) by typing the following:
| |
| | |
| <console>
| |
| # ##i##/root/metro/scripts/ezbuild.sh funtoo-current core2_32
| |
| </console>
| |
| | |
| In that case, the produced stages are placed in the <tt>/home/mirror/funtoo/funtoo-current/x32-bit/core2_32/YYYY-MM-DD</tt> subdirectory.
| |
| | |
| == Step 3: The Next Build ==
| |
| | |
| At this point, you now have a new Core_2 32bit stage3, built using a "remote" pentium4 stage3. Once the first remote build completes successfully, metro will automatically change <code>.control/strategy/build</code> to be <code>local</code> instead of <code>remote</code>, so it will use the most recently-built Core_2 32bit stage3 as a seed for any new Core_2 32bit builds from now on.
| |
| | |
| = Build your own tailored stage3 =
| |
| | |
| Metro can be easily configured for building custom stage3 by including additional packages. Edit the following configuration file <tt>/root/metro/etc/builds/funtoo-current/build.conf</tt>:
| |
| {{file|name=funtoo-current/build.conf|body=
| |
| [collect ../../fslayouts/funtoo/layout.conf]
| |
| | |
| [section release]
| |
| | |
| author: Daniel Robbins <drobbins@funtoo.org>
| |
| | |
| [section target]
| |
| | |
| compression: xz
| |
| | |
| [section portage]
| |
| | |
| FEATURES:
| |
| SYNC: $[snapshot/source/remote]
| |
| USE:
| |
| | |
| [section profile]
| |
| | |
| format: new
| |
| path: gentoo:funtoo/1.0/linux-gnu
| |
| arch: $[:path]/arch/$[target/arch_desc]
| |
| build: $[:path]/build/current
| |
| flavor: $[:path]/flavor/core
| |
| mix-ins:
| |
| | |
| [section version]
| |
| | |
| python: 2.7
| |
| | |
| [section emerge]
| |
| | |
| | |
| [section snapshot]
| |
| | |
| type: live
| |
| compression: xz
| |
| | |
| [section snapshot/source]
| |
| | |
| type: git
| |
| branch: funtoo.org
| |
| # branch to have checked out for tarball:
| |
| branch/tar: origin/master
| |
| name: ports-2012
| |
| remote: git://github.com/funtoo/ports-2012.git
| |
| options: pull
| |
| | |
| [section metro]
| |
| | |
| options:
| |
| options/stage: cache/package
| |
| target: gentoo
| |
| | |
| [section baselayout]
| |
| | |
| services: sshd
| |
| | |
| [section multi]
| |
| | |
| snapshot: snapshot
| |
| | |
| [section files]
| |
| | |
| motd/trailer: [
| |
| | |
| >>> Send suggestions, improvements, bug reports relating to...
| |
| | |
| >>> This release: $[release/author]
| |
| >>> Funtoo Linux (general): Funtoo Linux (http://www.funtoo.org)
| |
| >>> Gentoo Linux (general): Gentoo Linux (http://www.gentoo.org)
| |
| ]
| |
| | |
| [collect ../../multi-targets/$[multi/mode:zap]]
| |
| }}
| |