[OpenBSD]

[Índice da FAQ] [Seção 4 - Guia de Instalação] [Seção 6 - Redes]

5 - Construção do Sistema a partir do Código Fonte


Conteúdo



5.1 - Os sabores ("Flavors") do OpenBSD

Existem três "sabores" do OpenBSD: Graficamente, o desenvolvimento dessas versões se parece com isto:
       ,------o-----------o----X                    4.4 Stable
       |      .           .
       |      .    ,------o---------o----X          4.5 Stable
       |      .    |      .         .
       |      .    |      .    ,----o----------o--> 4.6 Stable
       |      .    |      .    |    .          .
       |      .    |      .    |    .    ,-----o--> 4.7 Stable
       |      .    |      .    |    .    |     .
       |      .    |      .    |    .    |     .
 -->4.4Rel----->4.5Rel----->4.6Rel----->4.7Rel----> Current

          Tempo --->

-Current é onde o trabalho de desenvolvimento ativo é feito e, consequentemente, ela tornar-se-á a nova -release do OpenBSD. A cada seis meses, quando uma nova versão do OpenBSD é lançada, -current é marcada e torna-se -release: um ponto de congelamento na história da árvore de código fonte. Cada -release nunca é alterada; ela é a que está nos CDs e servidores FTP.

-Stable é baseada na -release, e é um ramo do caminho de desenvolvimento principal do OpenBSD. Quando correções muito importantes são feitas na -current, elas são portadas (integradas) para o ramo -stable; por causa disso, -stable também é conhecida como o "patch branch" (ramo corrigido). Na ilustração acima, as linhas verticais pontilhadas marcam correções de falhas incorporadas ao ramo -stable. Você também pode notar que no exemplo acima, o ramo 4.4-stable chega ao fim com o 4.6-release, e o ramo 4.5-stable chega ao fim com o 4.7-release -- releases antigas são tipicamente suportadas durante "duas releases" no máximo. Suportar versões antigas toma recursos e tempo; enquanto nós gostamos de oferecer suporte a releases antigas, nós preferencialmente nos focamos em novas funcionalidades. O ramo -stable é, pelo seu projeto, muito fácil de construir a partir da -release da mesma versão (ou seja, ir da 4.7-release para a 4.7-stable).

O ramo -stable é a -release mais as correções encontradas na página errata. O funcionamento da -stable é a mesmo em que a -release está baseada. Se as páginas de manual tiverem alguma mudança, ela provavelmente não vai para a -stable. Em outras palavras, o suporte a novos dispositivos e novas funcionalidades não serão adicionados à -stable.

É útil apontar que o nome "-stable" (estável) não significa que a -current é instável. Pelo contrário, -current está mudando e desenvolvendo-se, enquanto o funcionamento e as APIs da -stable não estão sendo mudados, assim você não tem que reaprender seu sistema, mudar quaisquer arquivos de configuração, ou acabar tendo algum problema ao adicionar aplicativos no seu sistema.

De fato, como nossa esperança é continuar melhorando o OpenBSD, o objetivo é que a -current deve ser mais estável, mais segura e, naturalmente, ter mais funcionalidades que a -stable. Assim sendo, a "melhor" versão do OpenBSD é a -current.

A maioria dos usuários devem usar tanto a -stable quanto a -release. Isso quer dizer que, muitas pessoas usam a -current como sistema de produção, e é importante que as pessoas façam isso para identificar falhas e testar novas funcionalidades. No entanto, se você não sabe como descrever corretamente, diagnosticar e lidar com um problema, não diga para você mesmo (ou a qualquer outra pessoa) que você está "ajudando o projeto" por usar a -current. "Isto não funciona!" não é um relato de falha útil. "As mudanças recentes no driver pciide quebraram a compatibilidade com minha interface IDE baseada no Slugchip, segue o dmesg do sistema funcionando e dele quebrado..." pode ser um relato útil.

Às vezes usuários "normais" querem viver no limite e usar a -current. A razão mais comum é que o usuário tem um dispositivo que não é suportado pela versão -release (e, assim, também não pela -stable), ou deseja usar uma nova funcionalidade da -current. Nesse caso, a escolha pode ser entre usar a -current ou não usar o dispositivo, e -current pode ser a escolha menos dolorosa. No entanto, não espere ajuda dos desenvolvedores.

Snapshots

Entre as releases formais do OpenBSD, as snapshots são disponibilizadas nos sítios FTP. Como o nome indica, estas são compilações de qualquer código fonte que estava na árvore no momento em que o construtor pegou uma cópia do código fonte para uma plataforma em particular. Lembre-se: em algumas plataformas pode-se levar DIAS até que uma snapshot seja terminada e colocada para distribuição. Não há promessa de que as snapshots são completamente funcionais, ou mesmo que instalam. Frequentemente, uma mudança que precisa ser testada pode ocasionar a criação de uma snapshot. Algumas plataformas têm snapshots criadas diariamente, outras em menor frequência. Se você deseja usar a -current, uma snapshot recente é normalmente tudo que você precisa, e atualizar a versão para uma snapshot é um ponto de partida exigido antes de tentar compilar a -current a partir do código fonte.

Uma pergunta frequente é se existe algum modo de pegar uma cópia exata do código fonte usado para compilar uma snapshot. A resposta é não. Primeiro, não existe benefício significante nisso. Segundo, as snapshots são criadas quando desejado, quando existe tempo, e quando os recursos estão disponíveis. Em plataformas lentas, pode-se levar uma semana ou mais para criar-se uma snapshot. A inclusão de marcas ou etiquetas na árvore de código fonte para cada snapshot não seria nem um pouco prático. Terceiro, snapshots frequentemente contêm código fonte experimental que ainda não foi incluído na árvore.

Upgrade vs. Update

Você irá ver com frequência referências a "upgrading" e "updating" na instalação do OpenBSD. Mesmo que essas palavras tenham significados parecidos, elas são usadas de maneira um pouco diferente no OpenBSD.

"Upgrading" (atualização de versão) é o processo de instalar uma nova versão do OpenBSD, com novas funcionalidades. Por exemplo, passar da v4.6 para a v4.7, ou passar da snapshot de 12 de junho para a snapshot de 20 de junho. Na atualização de versão, você terá que consultar tanto Seguindo a -current quanto o Guia de Atualização de Versão (ao mudar de release) para fazer as mudanças requeridas para usar a versão atualizada do OpenBSD.
"Updating" (atualização) é o processo de aplicar correções em um sistema para melhorar o funcionamento SEM mudar as funcionalidades básicas ou a compatibilidade binária. Isso é tipicamente feito utilizando o processo de correção de código fonte ou o documento Seguindo a -stable. Quando você faz uma atualização do seu sistema, ele vai de -release para -stable (ou -release corrigida) da mesma versão da release; por exemplo, 4.7-release para 4.7-stable. Você pode então mais tarde atualizar para uma nova -stable da mesma versão da release. O processo de atualização é tipicamente indolor, nem arquivos do diretório /etc nem outras configurações do sistema precisam ser mudados.

Desse modo, você pode instalar um sistema (por exemplo, 4.5-release) pelo CD, fazer poucas vezes a atualização dele para 4.5-stable, e então fazer a atualização para a versão 4.6-release pelo CD, e fazer a atualização desta poucas vezes antes da nova atualização de versão para a 4.7-release.

Mantendo as coisas sincronizadas

É importante entender que o OpenBSD é um sistema operacional, cuja a intenção é ser utilizado por completo, não um kernel com uma quantidade de utilidades integradas. Você precisa ter certeza de que seu kernel, espaço de usuário (as utilidades e arquivos de suporte) e árvore de portes estão todos sincronizados, ou coisas desagradáveis acontecerão. Dito de outra forma (porque alguns usuários seguem cometendo este erro), não é possível usar novos portes em um sistema que já tenha um mês, ou recompilar um kernel a partir do código fonte -current e esperar que ele trabalhe com o espaço de usuário da -release. Sim, isso significa que você precisa fazer a atualização de versão do seu sistema se você quer usar novos programas que foram adicionados hoje à árvore de portes. Desculpe-nos, mas repetindo: os recursos disponíveis do OpenBSD são limitados.

Outro fato a ser compreendido é que o processo de atualização de versão é suportado em somente uma direção: do antigo para o novo, e da -stable para a -current. Você não pode usar a 4.7-current (ou snapshot), e então decidir que você está vivendo muito perigosamente e voltar para a 4.7-stable. Você está em suas próprias mãos se decidir qualquer caminho contrário à opção suportada de recomeçar seu sistema do zero; portanto, não espere assistência da equipe de desenvolvimento do OpenBSD.

Sim, isso significa que você deve pensar bem e refletir antes de utilizar a -current.

5.2 - Por que eu preciso compilar meu sistema a partir do código fonte?

Na verdade, há muitas chances disso não ser necessário.

Algumas razões para NÃO compilar seu sistema a partir do código fonte:

Algumas razões pelas quais você realmente deseja ou precisa compilar a partir do código fonte:

A equipe do OpenBSD disponibiliza novas snapshots baseadas no código fonte da -current para todas as plataformas. Isso normalmente será tudo que você precisa para usar a -current.

A razão mais comum para compilar a partir do código fonte é seguir o ramo -stable, onde compilar a partir do código fonte é a única opção suportada.

5.3 - Compilação do OpenBSD a partir do código fonte

5.3.1 - Visão geral

Compilar o OpenBSD a partir do código fonte envolve os seguintes passos: Existem etapas suplementares que alguns usuários talvez queiram realizar, dependendo do propósito da compilação e da presença ou não do X:

5.3.2 - Instalação ou atualização de versão para os binários mais recentes

O primeiro passo na compilação a partir do código fonte é ter certeza que você tem os binários mais recentes instalados. Use esta tabela para procurar onde você está, aonde você deseja ir, e com qual binário começar:

Você está em Objetivo Atualização binária para então...
-release antiga Nova release Release atual Feito!
-release -stable Release Atual Baixar & compilar a -stable
-stable antiga -stable Release Atual Baixar & compilar a -stable
-release -current Última Snapshot (opcional) Baixar & compilar a -current
-current antiga -current Última Snapshot (opcional) Baixar & compilar a -current

É recomendado que você instale os binários usando a opção "Upgrade" da mídia de instalação. Se isso não é possível, você pode também descompactar os binários como descrito aqui. Você deve fazer o processo completo de atualização de versão, incluindo criar quaisquer usuários ou outras mudanças necessárias no diretório /etc.

5.3.3 - Download do código fonte apropriado

O código fonte do OpenBSD é gerenciado usando o sistema de controle de versão CVS, e cvs(1) é usado para puxar uma cópia do código fonte desejado para a sua máquina local, para os fins da compilação. Isso pode ser feito usando um servidor AnonCVS (uma máquina que guarda uma cópia de acesso público de todo o repositório CVS usado pelo projeto OpenBSD) ou de um repositório CVS local que você mantém usando o programa CVSup ou CVSync, disponíveis como pacotes. O CVSup pode também ser usado em modo "checkout", mas isso não será explicado aqui. Se você tem múltiplas máquinas e deseja manter as árvores de código fonte ativas, você deve utilizar um repositório CVS local, criado e mantido usando CVSup ou CVSync.

Depois de decidir qual servidor AnonCVS você deseja usar, você deve fazer o "checkout" da árvore de código fonte, depois disso você então mantém a árvore executando "updates" (atualizações), para puxar arquivos atualizados para a sua árvore local.

O comando CVS(1) tem muitas opções, algumas delas são requeridas para o checkout e update de uma árvore. Outros comandos podem causar a quebra da árvore. O fato de compreender e seguir estas direções é importante.

Seguindo a -current

Neste caso, assumimos que você está usando um servidor público AnonCVS, anoncvs@anoncvs.exemplo.org:/cvs. Nós também assumimos que você está usando o shell sh(1), se você está usando um shell diferente, você terá que fazer alguns ajustes nestes comandos.

Para fazer o checkout da árvore src CVS da -current, você pode usar o seguinte:

    # cd /usr
    # export CVSROOT=anoncvs@anoncvs.exemplo.org:/cvs
    # cvs -d$CVSROOT checkout -P src

Uma vez que você tem a árvore, você pode atualizar ela mais tarde com:

    # cd /usr/src
    # export CVSROOT=anoncvs@anoncvs.exemplo.org:/cvs
    # cvs -d$CVSROOT up -Pd
Seguindo a -Stable
Se você deseja pegar um "ramo" alternativo da árvore, tal como o ramo -stable, você deve usar o modificador "-r" em seu checkout:
    # cd /usr
    # export CVSROOT=anoncvs@anoncvs.exemplo.org:/cvs
    # cvs -d$CVSROOT checkout -rOPENBSD_4_7 -P src
Isso puxa os arquivos src do ramo OPENBSD_4_7, o qual é também conhecido como "Ramo corrigido" ou "-stable". Você também pode atualizar o código fonte assim:
    # cd /usr/src
    # export CVSROOT=anoncvs@anoncvs.exemplo.org:/cvs
    # cvs -d$CVSROOT up -rOPENBSD_4_7 -Pd
O CVS é realmente bom o bastante para afixar uma etiqueta nos arquivos verificados, assim você não tem que lembrar a parte "-rOPENBSD_4_7" da linha de comando; ele irá lembrar isso até que você explicitamente limpe ou configure uma nova etiqueta usando a opção "-A" no "update". No entanto, é provavelmente melhor colocar mais informações em suas linhas de comando CVS do que poucas.

Enquanto somente a árvore "src" esteve presente até o momento, você deve fazer os mesmos passos para "xenocara" e "ports". Como todas as partes do OpenBSD precisam estar em sincronia, todas as árvores que você usar devem ser verificadas e atualizadas ao mesmo tempo. Você pode juntar os checkouts em uma linha (-stable é mostrada):

    # export CVSROOT=anoncvs@anoncvs.exemplo.org:/cvs
    # cd /usr
    # cvs -d$CVSROOT checkout -rOPENBSD_4_7 -P src ports xenocara
No entanto, atualizações precisam ser feitas diretório por diretório.

Neste ponto, se você segue a -stable ou a -current, você já deve ter uma árvore de código fonte correta. Esteja atento sobre qual árvore você pegou -- você pode acabar tentando compilar a -current quando o objetivo é a -stable.

Pré-carregando a árvore: src.tar.gz, sys.tar.gz

Enquanto você pode fazer o download de toda a árvore de um servidor AnonCVS, você pode muitas vezes salvar tempo e banda de rede "pré-carregando" sua própria árvore de código fonte com os arquivos tanto do CD do OpenBSD quanto de um servidor FTP. Isso é particularmente verdadeiro se você está usando a -stable, com relativamente poucos arquivos alterados entre essa versão e a -release em que está baseada.

Para extrair a árvore de código fonte do CD para /usr/src (assumindo que o CD está montado em /mnt):

    # cd /usr/src; tar xzf /mnt/src.tar.gz
    # cd /usr; tar xzf /mnt/xenocara.tar.gz
    # cd /usr; tar xzf /mnt/ports.tar.gz
Os arquivos de código fonte disponíveis para download nos servidores FTP são separados em dois arquivos para minimizar o tempo de download para aqueles que querem trabalhar com somente uma parte da árvore. Os dois arquivos são sys.tar.gz, o qual contém os arquivos usados para a criação do kernel, e src.tar.gz, que contém todas as outras utilidades do espaço de usuário, exceto a árvore de portes e o código fonte do X11. Geralmente, no entanto, talvez você queira ambos instalados. Assumindo que os arquivos baixados, src.tar.gz e sys.tar.gz, estão em /usr:
    # cd /usr/src
    # tar xzf ../sys.tar.gz
    # tar xzf ../src.tar.gz
    # cd /usr
    # tar xzf xenocara.tar.gz
    # tar xzf ports.tar.gz

Nem todas as pessoas querem descompactar todos os pacotes de arquivos, mas conforme o sistema precisar ser colocado em sincronia, você geralmente terá a necessidade de configurar todas as partes da árvore.

Dicas comuns de CVS

Como mencionado anteriormente, algumas opções são obrigatórias para pegar uma árvore src válida no OpenBSD. A opção "-P" acima é uma delas: Ela faz "prunes" (remove) em diretórios que estão vazios. Com o passar do anos, diretórios foram criados e excluídos na árvore de código fonte do OpenBSD, e algumas vezes os nomes dos diretórios antigos são atualmente usados como nomes de arquivos. Sem a opção "-P", seu mais recente "checked-out" da árvore não irá compilar corretamente.

Muitas opções parecidas que usam -d no comando 'update' -- isso cria novos diretórios que podem ter sido adicionados na árvore desde seu checkout inicial. Para atualizar corretamente, você precisa usar as opções -Pd.

Usuários experientes de CVS podem se perguntar por que a CVSROOT foi especificada e usada nesse exemplo, quando o cvs(1) registra a localização do servidor CVS na árvore checada. Isso é correto, contudo, muitas vezes é um jeito necessário para sobrescrever o servidor anoncvs padrão, muitas pessoas recomendam sempre especificar explicitamente o repositório. É também de valia notar que enquanto a variável de ambiente CVSROOT pode ser usada diretamente pelo cvs(1), ela é usada somente se nenhuma outra sobrescrevê-la (ou seja, cvs(1) teria um erro sem ela), apesar de que especificar ela na linha de comando cvs(1) sobrescreve todos os outros valores.

É bastante útil usar um .cvsrc no seu diretório pessoal para especificar padrões para algumas dessas opções. Um exemplo de arquivo .cvsrc:

    $ more ~/.cvsrc
    cvs -q -danoncvs@anoncvs.exemplo.org:/cvs
    diff -up
    update -Pd
    checkout -P
Esse arquivo faz o cvs(1) usar o servidor anoncvs@anoncvs.exemplo.org:/cvs, suprimir saída desnecessária ("-q" é "quieto") para todas as operações, um comando "cvs up" padronizado para usar -Pd, um "cvs diff" padronizado para providenciar "unified diffs" imposto por "-u", e um "cvs checkout" usa a opção "-P". Enquanto isso é conveniente, se você se esquecer que esse arquivo existe, ou tentar executar comandos que você tem usado em uma máquina sem esse arquivo, você terá problemas.

Como a árvore de código fonte consiste, em sua maioria, de vários arquivos pequenos, ativar o soft updates para a partição que a árvore de código fonte está localizada vai melhorar significantemente o desempenho.

5.3.4 - Compilação do kernel

Nós assumimos que você deseja compilar um kernel padrão (GENERIC ou GENERIC.MP) aqui. Normalmente, isso é o que você deseja fazer. Não considere a ideia de compilar um kernel personalizado se você não dominou o processo de compilação padrão.

Obviamente, o kernel é uma porção do sistema MUITO dependente do hardware. O código fonte para o kernel está no diretório /usr/src/sys. Algumas partes do código fonte do kernel do OpenBSD são usadas em outras plataformas, outras são específicas de um processador ou de uma arquitetura. Se você olhar no diretório /usr/src/sys/arch/, você pode ver algumas coisas que parecem um pouco confusas -- por exemplo, existem os diretórios mac68k, m68k e mvme68k. Nesse caso, ambos os sistemas mvme68k e mac68k usam o mesmo processador, mas as máquinas em que eles são baseados são diferentes e, dessa forma, requerem um kernel diferente (há muito mais coisas sobre o projeto de um computador do que de seu processador!). No entanto, partes do kernel são comuns, e essas partes são mantidas no diretório m68k. Se você está simplesmente compilando um kernel, a base da arquitetura de diretórios como m68k não é nada para você se preocupar, você deve trabalhar exclusivamente com os diretórios da "área da arquitetura", tal como mvme68k.

Kernels são compilados baseados nos arquivos de configuração do kernel, que estão localizados no diretório /usr/src/sys/arch/<sua plataforma>/conf. A compilação do kernel consiste no uso do programa config(8) para criar e popular o diretório de compilação do kernel, que no fim estará em /usr/src/sys/arch/<sua plataforma>/compile/<Nome do Kernel>. Para este exemplo, nós assumimos que você está usando a plataforma i386:

# cd /usr/src/sys/arch/i386/conf
# config GENERIC
# cd ../compile/GENERIC
# make clean && make depend && make
    [...várias mensagens de saída...]
# make install
Troque "i386", na primeira linha, pelo nome da sua plataforma. O comando machine(1) pode dizer a você qual é o nome da sua plataforma, assim uma generalização óbvia pode ser usada com o comando "cd /usr/src/sys/arch/`machine`/conf" em vez da primeira linha.

Neste ponto, reinicialize sua máquina para ativar esse novo kernel. Note que o novo kernel deve estar em execução antes do próximo passo; de qualquer forma, se você seguiu o aviso acima sobre atualização de versão para o mais recente snapshot disponível, isso não é tão importante. Algumas vezes, no entanto, as APIs mudam e o kernel antigo fica impossibilitado de executar novas aplicações, mas o novo kernel geralmente suporta as antigas.

Variação do processo acima: Árvore de código fonte apenas para leitura ("Read-only")

Algumas vezes, você pode querer ter certeza que seu diretório /usr/src/sys permanecerá intocável. Isso pode ser feito usando o seguinte processo:
$ cd /qualquer_lugar
$ cp /usr/src/sys/arch/i386/conf/GENERIC .
$ config -s /usr/src/sys -b . GENERIC
$ make clean && make depend && make
   ... várias mensagens de saída ...
Note que você pode compilar o kernel sem acesso root, mas você precisa ter acesso ao root para instalar o kernel.

5.3.5 - Compilação do espaço de usuário

Há um processo específico usado pelo OpenBSD. Os processos usados em outros SOs que você tem familiaridade normalmente não irão funcionar no OpenBSD.

5.4 - Compilação de uma release

O que é uma "release", e por que eu vou querer fazer uma?

Uma release é um conjunto de arquivos completos que você pode usar para instalar o OpenBSD em outro computador. Se você tem somente um computador executando o OpenBSD, você realmente não tem nenhuma razão para fazer uma release; o processo de compilação acima vai fazer tudo que você precisa. Um exemplo de uso do processo de fazer uma release é compilar a -stable em uma máquina rápida, e então fazer uma release para ser instalada em todas as suas outras máquinas no seu escritório.

O processo de criar uma release usa os binários criados no diretório /usr/obj no processo de compilação mostrado acima, então você precisa primeiro completar corretamente a compilação, e nada deve atrapalhar o diretório /usr/obj. Um momento onde isso pode ser um problema é se você usa um disco de memória como seu /usr/obj, para um pouco de desempenho extra no processo de compilação: você não vai querer reinicializar seu computador entre os passos de "build" e "release"!

O processo de criar uma release requer dois diretórios para o trabalho, que nós vamos chamar de DESTDIR e RELEASEDIR. Todos os arquivos que são parte de uma instalação "limpa" do OpenBSD são copiados para seus lugares apropriados dentro do DESTDIR. Eles então são compactados com o tar(1) e colocados em RELEASEDIR. No fim do processo, RELEASEDIR guarda a release completa do OpenBSD. O processo de criar uma release também usa o /mnt, então este não deve ser usado por nada enquanto o processo de criação da release estiver em execução. Para propósitos de exemplo, nós usaremos o DESTDIR em /usr/dest e o RELEASEDIR em /usr/rel.

O processo de criar uma release envolve um utilitário, crunchgen(8), que é utilizado para criar um único arquivo executável feito de vários binários individuais. O nome como esse único arquivo executável é executado determina qual componente binário é executado. É dessa maneira que vários arquivos de programas individuais são comprimidos em um kernel ramdisk presente em disquetes de inicialização e outras mídias de inicialização.

Você precisa ter privilégios de root para fazer uma release.

Como fazer uma release

Defina nossas variáveis de ambiente DESTDIR e RELEASEDIR:
# export DESTDIR=/usr/dest
# export RELEASEDIR=/usr/rel
Nós agora limpamos DESTDIR e, se necessário, criamos os diretórios:
# test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}.old && rm -rf ${DESTDIR}.old &
# mkdir -p ${DESTDIR} ${RELEASEDIR}
RELEASEDIR normalmente não precisa ser esvaziado antes de começar o processo de fazer uma release; no entanto, se existem mudanças nos arquivos de release ou em seus nomes, arquivos antigos serão conservados. Você pode desejar também apagar esse diretório antes de começar.

Nós agora faremos a release em si:

# cd /usr/src/etc
# make release
Depois que a release está pronta, é uma boa ideia verificá-la para ter certeza de que os arquivos tar correspondem aos que estão no DESTDIR. A saída deste passo deve ser mínima.
# cd /usr/src/distrib/sets
# sh checkflist
Você agora tem o conjunto de arquivos completo e verificado em RELEASEDIR. Esses arquivos podem agora ser usados para a instalação ou atualização de versão do OpenBSD em outras máquinas.

As instruções confiáveis sobre como fazer uma release estão em release(8).

Nota: se você deseja distribuir os arquivos resultantes por HTTP, para uso em scripts de instalação ou upgrade, você também precisa adicionar um arquivo "index.txt", o qual contém a lista de todos os arquivos em sua recém-criada release.

# /bin/ls -1 >index.txt
Após você ter feito a release, você pode usar aqueles arquivos para uma instalação padrão ou atualização de versão de outra máquina, ou se for atualizar uma máquina para uma nova -stable, simplesmente descompacte os arquivos tar no diretório raiz da máquina de destino.

5.5 - Compilação do X (Xenocara)

A partir do X.org v7, o X mudou para um sistema de "compilação modular", dividindo a árvore de código fonte no X.org v7 em mais de trezentos pacotes mais ou menos independentes.

Para simplificar a vida dos usuários do OpenBSD, uma "meta-build" chamada Xenocara foi desenvolvida. Esse sistema "converte" o X novamente em uma grande árvore para ser compilada em um único processo. Como um bônus, esse processo é mais similar ao processo de compilação usado pelo resto do OpenBSD do que as versões anteriores eram.

As instruções oficiais para a compilação do X estão no arquivo /usr/xenocara/README e em release(8).

Como obter o código fonte

A localização "normal" para a árvore xenocara é /usr/xenocara, e o código fonte é guardado no módulo xenocara no CVS. Dessa forma, o processo de "checkout" é este:
$ cd /usr
$ cvs -qdanoncvs@anoncvs.exemplo.org:/cvs checkout -P xenocara

Compilação da Xenocara

Para a compilação da árvore xenocara padrão, suportada pelo OpenBSD, nenhuma ferramenta externa é necessária.
# cd /usr/xenocara
# rm -rf /usr/xobj/*
# make bootstrap
# make obj
# make build
Se você deseja fazer mudanças na árvore de código fonte, você irá provavelmente precisar adicionar vários pacotes. Detalhes estão no arquivo /usr/xenocara/README.

Como fazer uma release do X

Isso é similar ao processo de criar uma release do sistema principal. Depois de compilar corretamente o X, você vai definir as variáveis DESTDIR e RELEASEDIR, com os mesmos propósitos mostrados mais acima. O RELEASEDIR pode ser o mesmo diretório que o RELEASEDIR do sistema principal, mas DESTDIR é apagado e refeito nesse processo. Se feito cuidadosamente, isso não é um problema, mas usar um DESTDIR separado pode ser "mais seguro".

Para este exemplo, nós usaremos as variáveis DESTDIR e RELEASEDIR em /usr/dest e /usr/rel, respectivamente. Isso precisa ser feito depois do processo de compilação mostrado acima.

# export DESTDIR=/usr/dest
# export RELEASEDIR=/usr/rel
# test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}- && \
     rm -rf ${DESTDIR}- &
# mkdir -p ${DESTDIR} ${RELEASEDIR}
# make release
Quando esse processo completar, você terá um conjunto de arquivos de release em $RELEASEDIR.

5.6 - Por que eu preciso de um kernel personalizado?

Na verdade, você provavelmente não precisa.

Um kernel personalizado é uma compilação com um arquivo de configuração diferente daquele fornecido no arquivo de configuração GENERIC. Um kernel personalizado pode ser baseado no código fonte da -release, -stable ou -current, igual ao que um kernel GENERIC pode ser. Enquanto compilar seu próprio GENERIC, você terá suporte da equipe do OpenBSD, se compilar seu próprio kernel personalizado, você não terá.

A configuração do kernel padrão do OpenBSD (GENERIC) é projetada para ser útil para a maioria das pessoas. Muitas pessoas quebram seus sistemas, ao tentar otimizar o kernel, em vez de melhorar o funcionamento. Existem algumas pessoas que acreditam que você precisa personalizar seu kernel e o sistema para obter um desempenho otimizado, mas esse não é o caso do OpenBSD. Somente os usuários mais avançados e com conhecimentos nas aplicações exigentes precisam se preocupar com um kernel personalizado, ou com o sistema todo.

Algumas razões pelas quais você deseja ou precisa compilar um kernel personalizado:

Algumas razões pelas quais você não deve compilar um kernel personalizado:

Remover drivers de dispositivos pode acelerar o processo de inicialização no seu sistema, mas pode complicar a recuperação se você tiver um problema de hardware, além de ser, frequentemente, feito de forma errada. Remover drivers de dispositivos não vai fazer seu sistema funcionar mais rápido em qualquer quantidade notável, apesar de produzir um kernel pequeno. Remover a verificação e depuração de erro pode resultar em um ganho limitado de desempenho, mas ficará impossível descobrir problemas no sistema se alguma coisa não funcionar.

Novamente, desenvolvedores normalmente ignoram relatos de erro sobre kernels personalizados, a menos que o problema possa ser reproduzido em um kernel GENERIC. Você foi avisado.

5.7 - Compilação de um kernel personalizado

É assumido que você leu o texto acima e realmente adora sofrer. É também assumido que você tem um objetivo que não pode ser alcançado pela Configuração em tempo de inicialização (UKC>) nem config(8)urando o kernel GENERIC. Se todas as possibilidades são falsas, você deve parar de usar o GENERIC. Realmente.

A geração do kernel do OpenBSD é controlada por arquivos de configuração, que estão localizados nos diretórios /usr/src/sys/arch/<arch>/conf/ por padrão. Todas as arquiteturas possuem um arquivo, GENERIC, que é usado para gerar um kernel padrão do OpenBSD para aquela plataforma. Também podem existir outros arquivos de configuração que são usados para criar kernels com focos diferentes; por exemplo, para utilização mínima de RAM, estações de trabalho sem disco, etc.

O arquivo de configuração é processado pelo config(8), que faz a criação e população do diretório de compilação ../compile, em uma instalação típica, que será feita em /usr/src/sys/arch/<arch>/compile/. O config(8) também cria um Makefile e outros arquivos requeridos para uma compilação correta do kernel.

As opções de configuração do kernel são as opções que você adiciona na sua configuração do kernel para ativar certos recursos dele. Isso permite que você tenha exatamente o suporte que você quer, sem ter suporte para dispositivos desnecessários. Há um monte de opções que permitem que você personalize seu kernel. Aqui nós vamos ver somente algumas delas, aquelas que são de uso mais comum. Verifique na página de manual options(4) a lista completa de opções, e como esta muda de tempos em tempos, você deve ter certeza de que está usando a página de manual da mesma versão do OpenBSD que você está compilando. Você também pode verificar os exemplos de arquivos de configuração que estão disponíveis para a sua arquitetura.

Não adicione, remova, ou mude opções em seu kernel a menos que você tenha realmente uma razão para isso! Não edite o arquivo de configuração GENERIC!! A única configuração do kernel que é suportada pela equipe do OpenBSD é o kernel GENERIC, a combinação das opções em /usr/src/sys/arch/<arch>/conf/GENERIC e /usr/src/sys/conf/GENERIC distribuídas pela equipe do OpenBSD (ou seja, NÃO-editadas). Relatar um problema em um kernel personalizado quase sempre resulta em você ter que tentar reproduzir o problema com um kernel GENERIC. Nem todas as opções são compatíveis entre elas, e muitas opções são requeridas para um sistema trabalhar. Não há garantia de que apenas porque você conseguiu um kernel compilado e personalizado, ele irá funcionar. Não há garantia de que um kernel que pôde ser "config(8)urado" possa ser compilado.

Você pode ver os arquivos de configuração de plataformas específicas aqui:

Olhe com atenção esses arquivos e você irá notar uma linha perto do topo do arquivo, similar a esta:

     include "../../../conf/GENERIC"
Isso significa que ele está referenciando outro arquivo de configuração, um que armazena opções independentes da plataforma. Quando criar sua configuração do kernel, tenha certeza de olhar o conteúdo do sys/conf/GENERIC.

As opções de configuração do kernel devem ser colocadas no seu arquivo de configuração no formato:

option      nome
ou
option      nome=valor
Por exemplo, para ativar a opção "DEBUG" no kernel, adicione uma linha como esta:
option      DEBUG
Opções no kernel do OpenBSD são traduzidas em opções de pré-processador do compilador, então uma opção como DEBUG vai fazer com que o código fonte seja compilado com a opção -DDEBUG, que é equivalente a colocar um #define DEBUG nos arquivos de código fonte do kernel.

Algumas vezes você pode desejar desabilitar uma opção que está definida, tipicamente no arquivo "src/sys/conf/GENERIC". Enquanto você deve modificar uma cópia daquele arquivo, uma melhor escolha pode ser usar a instrução rmoption. Por exemplo, se você quer realmente desabilitar o depurador interno do kernel (não recomendado!), você deve adicionar uma linha igual a esta:

     rmoption DDB
em seu arquivo de configuração do kernel. A option DDB é definida em src/sys/conf/GENERIC, mas a linha rmoption acima desativa-a.

Novamente, por favor veja em options(4) mais informação sobre as especificações dessas opções. Também note que muitas das opções também têm suas próprias páginas de manual -- sempre leia todas as coisas disponíveis sobre uma opção antes de adicioná-la ou removê-la do seu kernel.

Compilação de um kernel personalizado

Neste caso, nós vamos compilar um kernel que suporta a placa serial ISA multiportas boca(4). Essa placa não está no kernel GENERIC, devido aos conflitos com outros drivers. Existem dois jeitos simples para fazer um kernel personalizado: copiar o arquivo de configuração GENERIC com um outro nome e editá-lo, ou criar um arquivo "invólucro" que inclui o kernel padrão GENERIC e quaisquer opções que você precise que não estão no GENERIC. Nesse caso, nosso arquivo invólucro se parece com isto:
include "arch/i386/conf/GENERIC"

boca0  at       isa? port 0x100 irq 10     # BOCA 8-port serial cards
com*   at       boca? slave ?
As duas linhas referentes à placa boca(4) são copiadas das linhas comentadas em GENERIC, com o IRQ ajustado se necessário. A vantagem de usar esse arquivo invólucro é que qualquer mudança não avisada no GENERIC é atualizada automaticamente com qualquer outra atualização de código fonte. A desvantagem é que não se pode remover dispositivos (apesar de que geralmente essa é uma ideia ruim, de qualquer forma).

Uma outra maneira de gerar um kernel personalizado é fazer uma cópia do GENERIC padrão, dando a ela um outro nome, e editando-a o quanto for necessário. A desvantagem disso é que atualizações posteriores no arquivo de configuração GENERIC precisam ser colocadas na sua cópia, ou você vai ter que refazer seu arquivo de configuração.

Em ambas as ocasiões, depois de fazer seu arquivo personalizado de configuração do kernel, use o config(8) e faça seu kernel como documentado acima.

Instruções completas para criar seu próprio kernel personalizado estão na página de manual config(8).

5.8 - Configuração em tempo de inicialização

Algumas vezes quando seu sistema está inicializando, pode ser que você receba a notícia de que o kernel achou seu dispositivo, mas talvez no IRQ errado. E talvez você precise usar esse dispositivo imediatamente. Bem, sem recompilar o kernel você pode usar a configuração do kernel em tempo de inicialização do OpenBSD. Isso somente corrige seu problema uma vez. Se você reinicializar, você terá que repetir esse procedimento. Assim sendo, isso é somente uma correção temporária, e você deve corrigir o problema usando o config(8). Seu kernel, no entanto, precisa da option BOOT_CONFIG; o kernel GENERIC possui essa opção.

Uma grande parte deste documento pode ser encontrada na página de manual boot_config(8).

Para inicializar no UKC ("User Kernel Config"), use a opção -c no momento da inicialização.

boot> boot hd0a:/bsd -c
Ou qualquer kernel que você queira inicializar. Fazendo isso, aparecerá um prompt UKC. A partir daí você pode passar comandos diretamente para o kernel, especificando dispositivos que você quer mudar ou desabilitar, ou mesmo ativar.

Aqui está uma lista de comandos comuns no UKC.

Uma vez que você tem seu kernel configurado, use quit ou exit e continue a inicialização. Depois disso, você deve fazer a mudança permanente em sua imagem do kernel, conforme descrito em Como usar o config(8) para alterar seu kernel.

5.9 - Como usar o config(8) para alterar seu kernel

As opções -e e -u com o config(8) podem ser extremamente úteis e salvar a perda de tempo compilando seu kernel. O sinalizador -e permite que você entre na configuração UKC em um sistema em funcionamento. Essas mudanças terão efeito após a próxima reinicialização. O sinalizador -u testa para ver se quaisquer mudanças foram feitas no sistema em funcionamento durante a inicialização, significando que você usou boot -c para entrar na configuração UKC enquanto seu sistema inicializava.

O exemplo seguinte mostra o desabilitamento dos dispositivos ep* no kernel. Por razões de segurança, você deve usar a opção -o que escreve as mudanças em um arquivo especificado. Por exemplo: config -e -o bsd.new /bsd grava as mudanças em bsd.new. O exemplo não usa a opção -o, então mudanças são apenas ignoradas, e não são escritas de volta no arquivo binário do kernel. Para mais informações relacionadas a erros e mensagens de aviso, leia a página de manual config(8).

$ sudo config -e /bsd
OpenBSD 4.7 (GENERIC) #558: Thu Mar  17 20:46:15 MDT 2010
    deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
warning: no output file specified
Enter 'help' for information
ukc> ?
        help                                Command help list
        add             dev                 Add a device
        base            8|10|16             Base on large numbers
        change          devno|dev           Change device
        disable         attr val|devno|dev  Disable device
        enable          attr val|devno|dev  Enable device
        find            devno|dev           Find device
        list                                List configuration
        lines           count               # of lines per page
        show            [attr [val]]        Show attribute
        exit                                Exit, without saving changes
        quit                                Quit, saving current changes
        timezone        [mins [dst]]        Show/change timezone
        bufcachepercent [number]            Show/change BUFCACHEPERCENT
        nkmempg         [number]            Show/change NKMEMPAGES
        shmseg          [number]            Show/change SHMSEG
        shmmaxpgs       [number]            Show/change SHMMAXPGS
ukc> list
  0 video* at uvideo* flags 0x0
  1 audio* at uaudio*|btsco*|sb0|sb*|gus0|pas0|sp0|ess*|wss0|wss*|ym*|eap*|envy*
|eso*|sv*|neo*|cmpci*|clcs*|clct*|auacer*|auglx*|auich*|auixp*|autri*|auvia*|aza
lia*|fms*|maestro*|esa*|yds*|emu* flags 0x0
  2 midi* at umidi*|sb0|sb*|opl*|opl*|opl*|opl*|opl*|ym*|mpu*|mpu*|autri*|eap* f
lags 0x0
  3 midi* at pcppi0 flags 0x0
  4 drm* at inteldrm*|radeondrm* flags 0x0
  5 inteldrm* at vga0|vga* flags 0x0
  6 radeondrm* at vga0|vga* flags 0x0
  7 radio* at udsbr*|bktr0|fms* flags 0x0
  8 softraid0 at root flags 0x0
  9 nsphy* at url*|udav*|mos*|axe*|aue*|xe*|ef*|hme*|lii*|bce*|ale*|age*|jme*|et
*|nfe*|stge*|vge*|bnx*|bge*|lge*|nge*|msk*|sk*|ste*|sis*|wb*|tl*|vr*|pcn*|sf*|ge
m*|ne0|ne1|ne2|ne*|ne*|ne*|epic*|sm0|sm*|dc*|dc*|re*|re*|rl*|rl*|mtd*|fxp*|fxp*|
xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|ep*|ep* phy -1 flags 0x0
 10 nsphyter* at url*|udav*|mos*|axe*|aue*|xe*|ef*|hme*|lii*|bce*|ale*|age*|jme*
|et*|nfe*|stge*|vge*|bnx*|bge*|lge*|nge*|msk*|sk*|ste*|sis*|wb*|tl*|vr*|pcn*|sf*
|gem*|ne0|ne1|ne2|ne*|ne*|ne*|epic*|sm0|sm*|dc*|dc*|re*|re*|rl*|rl*|mtd*|fxp*|fx
p*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|ep*|ep* phy -1 flags 0x0
[...recorte...]
ukc> disable ep
 98 ep0 disabled
 99 ep* disabled
100 ep* disabled
278 ep0 disabled
279 ep0 disabled
280 ep* disabled
281 ep* disabled
344 ep* disabled
ukc> quit
not forced

No exemplo acima, todos os dispositivos ep* são desativados no kernel e não serão examinados. Em algumas situações onde você tem usado o UKC durante a inicialização, via boot -c, você precisa dessas mudanças escritas permanentemente. Para fazer isso, você deve usar a opção -u. No exemplo seguinte, o computador foi inicializado em UCK e o dispositivo wi(4) foi desabilitado. Desde que as mudanças feitas com boot -c NÃO são permanentes, essas mudanças precisam ser gravadas. Este exemplo grava as mudanças feitas a partir do boot -c em um novo arquivo binário de kernel chamado bsd.new.

$ sudo config -e -u -o bsd.new /bsd
OpenBSD 4.6 (GENERIC) #58: Thu Jul  9 21:24:42 MDT 2009
    deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Processing history...
162 wi* disabled
163 wi* disabled
416 wi* disabled
Enter 'help' for information
ukc> quit

5.10 - Como obter mais mensagens durante a inicialização

Obter mais mensagens de saída pode ser muito útil para tentar depurar problemas durante a inicialização. Se você tem um problema onde seu disquete de inicialização não inicializa e precisa obter mais informação, simplesmente reinicialize. Quando você entrar no prompt "boot>", inicialize com boot -c. Isso levará você ao UKC>, então faça:
UKC> verbose
autoconf verbose enabled
UKC> quit

Agora você tem muitas mensagens de saída quando inicializar.

5.11 - Problemas comuns, dicas e perguntas sobre compilação e construção

Na maioria das vezes, problemas no processo de compilação são causados por não se seguir cuidadosamente as direções mostradas acima. Existem, ocasionalmente, problemas reais com a compilação da versão -current da mais recente snapshot, mas falhas durante a compilação da -release ou -stable são quase sempre erro do usuário.

A maioria dos problemas são normalmente um dos seguintes:

Estes são alguns problemas adicionais que você pode encontrar, no entanto:

5.11.1 - A compilação para com um erro "Signal 11"

A compilação do OpenBSD e outros programas a partir do código fonte é uma tarefa que exige mais do hardware do que outras coisas, fazendo uso intensivo de CPU, disco e memória. Como resultado, se você possui um hardware que tem um problema, o momento mais apropriado para o problema aparecer é durante uma compilação. Erros "Signal 11" são causados tipicamente por problemas de hardware, muitas vezes problemas de memória, mas também pode ser CPU, placa-mãe, ou problemas de aquecimento. Seu sistema pode realmente ser muito estável, mas incapaz de compilar programas.

Você provavelmente achará melhor reparar ou trocar os componentes que estão causando problemas, pois os problemas podem se manifestar de outras formas no futuro. Se você tem um hardware onde você realmente deseja usar e não te causa outro problema, simplesmente instale uma snapshot ou uma release.

Para muito mais informação, veja a FAQ Sig11.

5.11.2 - "make build" falha com a mensagem "cannot open output file snake: is a directory"

Esse é o resultado de dois erros separados: É importante seguir cuidadosamente as instruções ao baixar e compilar sua árvore.

5.11.3 - Meu sistema sem IPv6 não funciona!

Sim. Por favor, não faça modificações na base do sistema onde você não entende as implicações delas. Uma "pequena" mudança no kernel pode ter um impacto muito forte no resto do sistema inteiro. Por favor, releia isto.

5.11.4 - Opa! Eu esqueci de criar o diretório /usr/obj antes de começar!

Ao fazer um "make build" antes de um "make obj", você terminará com os arquivos de objetos espalhados em seu diretório /usr/src. Isso é uma coisa ruim. Se você deseja tentar evitar fazer novamente o download de toda a árvore src, você pode tentar o seguinte para limpar seus arquivos obj:
    # cd /usr/src
    # find . -type l -name obj | xargs rm
    # make cleandir
    # rm -rf /usr/obj/*
    # make obj

5.11.5 - Dica: Coloque o diretório /usr/obj em sua própria partição

Se você compila muitas vezes, pode achar mais rápido colocar o /usr/obj em sua própria partição. O benefício é simples, é tipicamente mais rápido:
    # umount /usr/obj
    # newfs YourObjPartition
    # mount /usr/obj
do que "rm -rf /usr/obj/*".

5.11.6 - Como não compilar partes da árvore?

Algumas vezes você pode desejar não compilar certas partes da sua árvore, tipicamente porque você tem instalado um substituto para uma aplicação incluída a partir dos pacotes, ou deseja fazer uma release "pequena" por qualquer razão. A solução para isso é usar a opção SKIPDIR do /etc/mk.conf.

Nota: é possível fazer um sistema quebrado desse modo. Os resultados dessa opção não são suportados pelo projeto OpenBSD.

5.11.7 - Onde eu posso aprender mais sobre o processo de compilação?

Aqui estão algumas outras fontes:

5.11.8 - Eu não vejo nenhuma snapshot no sítio FTP. Para onde elas foram?

Snapshots podem ser removidas quando elas se tornam velhas (ou irrelevantes) ou aproxima-se o momento de uma nova -release.

5.11.9 - Como iniciar uma nova versão do compilador (gcc)?

Você deve realmente apenas instalar a última snapshot.

O OpenBSD agora suporta dois compiladores na árvore, o gcc v3.3.5, usado pela maioria das plataformas, mas também o gcc v2.95.3, usado por algumas plataformas que não foram convertidas ainda, ou que não serão convertidas devido à carência de suporte ou desempenho pobre do gcc3.

Os dois compiladores estão em diferentes partes da árvore:

A atualização de versão de um compilador é um pouco como o problema da galinha e do ovo; mudanças no compilador da árvore requerem uma atenção extra. Você tem que compilar o compilador duas vezes -- o primeiro processo de compilação produz um compilador que gera novo código, mas executa com o código gerado pelo compilador antigo, o segundo processo de compilação produz um compilador completamente novo. Geralmente, você vai querer fazer o seguinte procedimento:

    Se a sua plataforma usa o gcc 2.95.3:
       # rm -r /usr/obj/gnu/egcs/gcc/*
       # cd /usr/src/gnu/egcs/gcc
        - ou -
    Se a sua plataforma usa o gcc 3.3.5:
       # rm -r /usr/obj/gnu/usr.bin/gcc/*
       # cd /usr/src/gnu/usr.bin/gcc

    Procedimento de compilação similar para v3.3.5 e v2.95.3
    # make -f Makefile.bsd-wrapper clean
    # make -f Makefile.bsd-wrapper obj
    # make -f Makefile.bsd-wrapper depend
    # make -f Makefile.bsd-wrapper
    # make -f Makefile.bsd-wrapper install
    # make -f Makefile.bsd-wrapper clean
    # make -f Makefile.bsd-wrapper depend
    # make -f Makefile.bsd-wrapper
    # make -f Makefile.bsd-wrapper install

E então execute um make build normalmente.

5.11.10 - Qual é o melhor jeito de atualizar /etc, /var e /dev?

Como uma política, software na árvore do OpenBSD não faz modificações no /etc automaticamente. Isso significa que ele sempre deixa para o administrador fazer as modificações necessárias aqui. Atualizações de versão não são exceções. Para atualizar os arquivos nesses diretórios, primeiro determine que mudanças ocorreram nos arquivos da base (distribuição), e então repita manualmente essas mudanças.

Por exemplo, para ver os arquivos na árvore que foram modificados mais recentemente, faça um:

    # cd /usr/src/etc
    # ls -lt |more

Para ver todas as mudanças no /etc, entre versões arbitrárias do OpenBSD, você pode usar o CVS. Por exemplo, para ver as mudanças entre 4.6 e 4.7, faça um:

    # cd /usr/src/etc
    # cvs diff -u -rOPENBSD_4_6 -rOPENBSD_4_7
Para ver as mudanças entre 4.7 e -current ("HEAD"), use:
    # cd /usr/src/etc
    # cvs diff -u -rOPENBSD_4_7 -rHEAD
O script /dev/MAKEDEV não é atualizado automaticamente como parte do processo make build, no entanto ele é instalado como parte de uma atualização de versão binária. Como regra geral, é uma boa ideia copiar (se necessário) e executar esse script a partir da árvore de código fonte quando estiver fazendo a atualização de versão:
    # cd /dev
    # cp /usr/src/etc/etc.`machine`/MAKEDEV ./
    # ./MAKEDEV all

Uma vez identificadas as mudanças, aplique-as em sua árvore local, preservando qualquer configuração local que você tenha feito.

As mudanças típicas em /etc a considerar, entre as releases, incluem:

Essas mudanças são sumarizadas em upgrade47.html (para ir para 4.7-release) ou current.html (para ir para -current).

5.11.11 - Há algum jeito fácil de fazer todas as mudanças nos arquivos da hierarquia?

De tempos em tempos, arquivos e diretórios são adicionados ou removidos do arquivo hierarchy. Além disso, a informação de propriedade de partes do sistema de arquivos pode mudar. Um jeito fácil de assegurar que sua hierarquia está em dia é usar o utilitário mtree(8).

Primeiramente, baixe o código fonte mais recente, então faça o seguinte:

    # cd /usr/src/etc/mtree
    # install -c -o root -g wheel -m 600 special /etc/mtree
    # install -c -o root -g wheel -m 444 4.4BSD.dist /etc/mtree
    # mtree -qdef /etc/mtree/4.4BSD.dist -p / -u

Sua hierarquia de arquivos deve estar em dia agora.

5.11.12 - Posso fazer compilação cruzada? Por que não?

Ferramentas de compilação cruzada estão no sistema, para uso pelos desenvolvedores para a criação de suporte às novas plataformas. No entanto, elas não são mantidas para uso geral.

Quando os desenvolvedores trazem o suporte para uma nova plataforma, um dos primeiros grandes testes é a compilação nativa. Compilar o sistema a partir do código fonte coloca uma considerável carga no SO e na máquina, e faz um bom trabalho de testar o quanto bem o sistema trabalha. Por essa razão, o OpenBSD faz todo o processo de compilação na plataforma onde a compilação será usada, processo também conhecido como "compilação nativa". Sem a compilação nativa é muito mais difícil ter certeza de que as várias plataformas estão realmente em funcionamento estável, e não apenas inicializando.

[Índice da FAQ] [Seção 4 - Guia de Instalação] [Seção 6 - Redes]


[voltar] www@openbsd.org
$OpenBSD: faq5.html,v 1.11 2010/06/19 07:38:08 ajacoutot Exp $