O servidor Git rivendell fornece repositórios para todos os projetos *LFS (e alguns outros). O repositório no qual nós estamos interessados para edição LFS é (não surpreendentemente) o repositório LFS. Uma lista completa dos módulos os quais estão disponíveis pode ser encontrada usando a interface do navegador do fonte do Trac em https://wiki.linuxfromscratch.org/lfs/browser.

Existem dois tipos de acesso Git para a árvore do LFS. Primeiro, existe o acesso somente leitura anônimo o qual qualquer pessoa pode usar. Segundo, existe o acesso leitura e escrita concedido para editores(as) ativos(as).

Para obter acesso anônimo, simplesmente use o comando seguinte (observe que isto assume que você está usando o bash ou um shell similar):

git clone git://git.linuxfromscratch.org/lfs.git lfs-git

Isso copiará o repositório público para um subdiretório chamado .git no diretório lfs-git e então copiará a ramificação padrão para esse diretório. Ele [o comando] também configurará o repositório local para rastrear a ramificação padrão do repositório público, de forma que você pode atualizar seu repositório local simplesmente executando (depois de mudar para o diretório lfs-git):

git pull

Observe que para o livro LFS, a ramificação padrão é chamada de trunk.

Para editores(as), o acesso é ligeiramente mais complicado. Você primeiro precisa gerar um par de chaves ssh. Para gerar as chaves execute:

ssh-keygen -t ed25519

Quando perguntado(a) onde salvar elas, provavelmente é melhor deixá-las em .ssh (como id_ed25519 e id_ed25519.pub). Quando perguntado(a) por uma frase senha, apenas pressione enter, a menos que você queira dar a frase a cada vez que você sincronizar para o servidor. Entretanto, dado que a mesma frase senha será usada quando você se logar no rivendell via ssh, talvez seja aconselhável ter alguma segurança no lugar.

Tendo gerado suas chaves, envie o ~/.ssh/id_ed25519.pub para um(a) administrador(a) do LFS para a finalidade de ter ela adicionada ao ~git/.ssh/authorized_keys no rivendell. Se você estará obtendo uma conta de login no servidor, [então] o(a) administrador(a) usará a mesma chave para permitir a você o acesso ssh.

Sua cópia local do id_ed25519 e id_ed25519.pub deveria permanecer intocado por esse processo.

Uma vez que esse processo esteja completo, tente copiar a revisão mais recente do livro LFS executando (a partir da sua máquina local):

git clone git@git.linuxfromscratch.org:lfs.git lfsbook

Se tudo for bem, [então] você baixará uma cópia do repositório atual para o lfsbook/.git e você copiará a ramificação padrão, a qual é chamada de trunk. Você também terá acesso de escrita, de forma que, de agora em diante, seja extra cuidadoso(sa). Observe que nenhuma mudança será feita até que você emita um comando git push.

O acima está bom para obter a ramificação padrão, porém você talvez queira trabalhar em uma ramificação pública diferente. Para configurar uma ramificação local que rastreie uma ramificação pública chamada new_branch, apenas emita:

git checkout --track origin/<new_branch>

Se você precisar trabalhar na ramificação padrão chamada trunk, [então] apenas comite suas mudanças (se alguma) para a ramificação nova (o commit é local), e mude de volta para trunk com:

git checkout trunk

Dado que a ramificação nova já está configurada, se você quiser novamente trabalhar na ramificação nova, apenas faça:

git checkout <new_branch>

Como com o acesso anônimo, você pode atualizar seu repositório local simplesmente emitindo um cd para o diretório LFS e executando:

git pull

Vamos nos tornar familiarizados(as) com o conjunto básico de comandos os quais todos(as) os(as) editores(as) usarão em uma quase sempre base diária. Existem muitas mais opções disponíveis que as listadas aqui, de forma que você desejará ler a documentação do Git (Pro Git) em algum ponto. git help também fornece uma referência rápida útil para os comandos do Git. As vezes git status mostra um par de comandos que um(a) usuário(a) poderia querer executar no atual estado do repositório.

git clone. Esse comando é usado para copiar um repositório público para a máquina local e fazer um checkout da ramificação padrão (trunk para o LFS). Você deveria precisar fazer isso somente uma vez. Várias opções permitem a criação de um repositório “raso” que não contém o histórico completo ou todas as ramificações. Veja-se git help clone.

Exemplos

Para clonar o repositório do LFS com acesso somente leitura:

git clone git://git.linuxfromscratch.org/lfs.git lfsbook

Para clonar com acesso leitura/escrita:

git clone @git.linuxfromscratch.org:lfs.git lfsbook

git pull. Esse comando sincroniza seu repositório local. Se você tiver feito mudanças locais, [então] o Git tentará mesclar quaisquer mudanças no servidor com as mudanças que você tiver comitado na sua máquina. Se as mudanças no servidor sobrepuserem com as mudanças locais não comitadas, [então] a mesclagem é cancelada, e a árvore de trabalho permanecerá intacta.

Diferente de svn up, quando o Git mescla seus commits locais com as mudanças no servidor, ele produzirá um commit de mesclagem. Muitos commits de mesclagem talvez causem confusão no histórico. Como uma alternativa, uma pessoa pode passar --rebase para git pull, dizendo ao Git para fazer o rebase de seus commits locais nas mudanças no servidor. Leia-se git rebase para os detalhes acerca de rebasing.

Para tornar um histórico limpo, os(as) editores(as) deveriam usar rebasing em vez de mesclagem para sincronizar as mudanças no servidor se você tiver alguns commits locais. Para tornar --rebase o padrão para git pull, emita: git config pull.rebase true.

Você deveria sempre fazer um git pull manual antes de tentar enviar mudanças para a finalidade de assegurar que não existem conflitos com mudanças que tenham sido feitas desde que você iniciou seu trabalho. Observe que git push advertirá você se existir um conflito e você se esquecer se realizar um git pull.

git add [arquivos-modificados]. Isso prepara as modificações para todos os arquivos-modificados (incluindo arquivos criados recentemente) para o índice. Se você especificar um diretório em arquivos-modificados, [então] todos os arquivos modificados nesse diretório ou nos subdiretórios dele serão preparados. A mudança não está no repositório local até que você faça um git commit. Nós tocaremos mais nisso conforme continuemos no capítulo.

Esse comando pode ser usado de uma maneira muito flexível usando-se a opção -p. Você pode selecionar cada pedaço do diff que está preparado dentro do índice. Isso permite testar uma mudança completa e então divide os commits em pequenos pedaços “atômicos” que são mais fáceis para revisar e entender.

git rm. Isso remove um arquivo e deixa o Git saber acerca dele. Várias opções permitem selecionar quando o arquivo é deletado somente no índice ou em ambos no índice e no diretório de trabalho. Observe que você precisa comitar (e possivelmente realizar um push) para a remoção aparecer no repositório.

git mv. Isso renomeia ou move um arquivo e deixa o Git saber acerca dele. Novamente, você precisa comitar (e possivelmente realizar um push) para a mudança aparecer no repositório.

git status. Esse provavelmente é o comando que você usará mais frequentemente. Ele imprime os arquivos que foram modificados no diretório de trabalho, e que não estão no índice; ou que estão no índice e não comitados ainda. Ele também mostra o estado do repositório local respectivo ao remoto.

Uma característica muito útil é a de que ele mostra uma lista de comandos que podem ser usados no contexto atual.

git commit. Esse comando armazena suas mudanças para o repositório local. Normalmente ele comita mudanças preparadas no índice, porém várias opções permitem que você contorne a preparação. Observe que nada é mudado no servidor até que você emita git push. As opções -m e -F podem ser usadas para passar uma mensagem de registro para o comando. Se você não especificar uma opção -m "MENSAGEM" ou -F "Nomearquivo", [então] o Git abrirá o editor padrão e solicitará que você digite uma mensagem de registro. O editor padrão é especificado pelas variáveis de ambiente, GIT_EDITOR; ou VISUAL; ou EDITOR (verificadas nessa ordem); ou por um parâmetro de configuração em ~/.git/config. Por exemplo, para configurar seu editor padrão para o vim, execute:

export GIT_EDITOR=vim

ou:

git config --global core.editor vim

Não use mensagens de registro vazias (veja-se posteriormente neste documento acerca da política que as rege).

git log. Gera o registro do commit da ramificação atualmente no diretório de trabalho. Várias opções permitem personalizar o nível da informação dada para cada commit. Os(As) Editores(as) são fortemente aconselhados(as) a executar esse comando antes de realizar um push para o repositório remoto ou mesclagem. Se o histórico for muito complicado, [então] talvez seja necessário executar git rebase para a finalidade de simplificá-lo. Seus(uas) coeditores(as) odiarão você se você mudar o histórico depois de realizar um push dele.

git push. Esse comando sincroniza o repositório público no servidor com o seu local. Você deveria ter certeza de que você quer publicar todos os commits que você tenha feito. As vezes, talvez seja útil executar git rebase -i para a finalidade de simplificar o histórico. Também, para prevenir conflitos quando se realizar um push, é melhor primeiro usar git pull antes de realizar um push e resolver quaisquer conflitos localmente.

git checkout. Esse comando é usado para tornar uma ramificação do repositório local visível no diretório de trabalho.

git merge. Isso é útil para aplicar mudanças originárias de outra ramificação (ou várias ramificações) para a atual. Por padrão, as mudanças resultantes são comitadas. Isso pode ser evitado com a opção --no-commit, a qual dá a você uma chance para inspecionar e ajustar ainda mais o resultado da mesclagem antes de comitar.

Em alguns casos, a mesclagem resulta em conflitos que tem de ser resolvidos manualmente. Observe que as edições deveriam mesclar apenas para uma ramificação limpa, isto é, após comitar todas as mudanças.

git rebase. Isso é útil para ter a ramificação atual iniciada a partir de outro ponto no histórico. Por exemplo, se você tiver:

                              B1---B2---B3    my_branch
                             /
                            A---C1---C2       trunk

realizar um rebase de my_branch para a trunk produzirá:

                              B'1---B'2---B'3 my_branch
                             /
                   A---C1---C2                trunk

onde o estado alcançado depois do commit B'3 é o mesmo que era em B3.

Porém, o comando mais útil é o git rebase -i que permite a você reescrever o histórico quando você tiver feito commits confusos.

Aqui está uma lista do sumário das coisas a fazer antes de comitar mudanças:

Você normalmente deveria restringir um commit a um conjunto de mudanças, de forma que se você estiver atualizando as versões de três pacotes, [então] usualmente você fará isso em três commits. Claramente, o que forma um "conjunto" é uma questão para seu julgamento. Sempre pense que um conjunto terá que ser mesclado para (ao menos) a ramificação multilib. Realizar um push não é obrigatório depois de cada mudança se você planeja breve fazer outra. Mais uma vez, os(as) editores(as) deveriam executar git pull antes de realizar um push para a finalidade de resolver qualquer conflito localmente.

Os(As) editores(as) do livro LFS preferem que as mudanças para a data em general.ent sejam feitas como parte de uma mudança real.

Isso talvez pareça realmente óbvio, porém é muito fácil cometer um erro de digitação em mudanças de comando de instalação que fazem com que a instalação quebre. Todos nós cometemos; você provavelmente também cometerá eventualmente. Entretanto, verifique duplamente para minimizar a chance.

Os seguintes elementos deveriam ser descomentados e atualizados no arquivo general.ent quando um lançamento (incluindo lançamentos -rc) for feito e as duas linhas acerca do version.ent deveriam ser comentadas:

<!ENTITY version         "10.2-rc1">
<!ENTITY versiond        "10.2-rc1">
<!ENTITY releasedate     "August 26th, 2021">
<!ENTITY copyrightdate   "1999-2021">

Para instantâneos de desenvolvimento, essas entidades são geradas automaticamente a partir da informação de commit do Git. Assim, o general.ent não precisa ser atualizado.

As atualizações do registro das mudanças sempre deveriam ser fornecidas, com a exceção dos pequenos consertos dos erros de digitação. Você não precisa adicionar "consertado um pequeno erro de digitação em XXX" ao registro das mudanças, do contrário ele crescerá demais.

As atualizações do registro das mudanças precisam estar no seguinte formato:

<listitem>
  <para>Dia, Mês e Ano</para>
  <itemizedlist>
    <listitem>
      <para>[nome de usuário(a)] - O que você mudou.</para>
    </listitem>
<!-- caso se aplique somente para a versão sysv (adapte para systemd) -->
    <listitem revision="sysv">
      <para>[nome de usuário(a)] - O que você mudou somente para a versão sysv.</para>
    </listitem>
    <listitem>
      <para>[nome de usuário(a)] - Entrada anterior do registro 
      das mudanças originária do mesmo dia, por você ou outro(a) 
      editor(a).</para>
    </listitem>
  <itemizedlist>
</listitem>

Exemplo:

<listitem>
  <para>03 de março de 2006</para>
  <itemizedlist>
    <listitem>
      <para>[renodr] - Atualização para o attr-2.5.1. Conserta
      <ulink url="&lfs-ticket-root;4833">#4833</ulink>.</para>
    </listitem>
  </itemizedlist>
</listitem>

As entradas do registro das mudanças sempre estão no topo da entrada do registro das mudanças adicionada anteriormente.

Se você estiver adicionando arquivos, [então] você precisa executar um comando git add em cada um deles. Quando você remover arquivos, você sempre deveria fazer isso com git rm. Mover ou renomear arquivos é feito com git mv. Adicionar um diretório e todos os filhos dele é feito com git add <nome_diretório>.

Se você pensa que está pronto para [efetivar o] commit, [então] execute git status para ver o estado da cópia de trabalho. O processo normal é primeiro [executar] git add [para adicionar] os arquivos que estão modificados ao índice, então executar git commit para armazenar o conjunto de mudanças no repositório local. A saída do git status se parece com isto:

On branch trunk
Your branch is up to date with 'origin/trunk'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   TODO

onde a [mensagem] "Changes to be committed" aparece em verde, enquanto que a [mensagem] "Changes not staged for commit" aparece em vermelho.

As vezes, uma mudança tornará alguma coisa não mais apropriada, porém você pensa que ela seria necessária no futuro. Se você comentá-la da maneira normal e iniciar o comentário com um marcador FIXME:, [então] isso será realçado sempre que o arquivo for editado, ao menos se você usar o vim.

Se você encontrar um FIXME: em um comentário, [então] não assuma automaticamente que ele possa ser deletado porque as instruções seguintes agora tenham sido comentadas.

Observe que não existe exemplo aqui - a renderização do html retira os comentários e uma caixa vazia parece idiota. Como sempre, renderize a sua cópia local depois que você comentar alguma coisa, de forma que você possa ver o resultado!

Tão logo você tiver certeza de que tudo renderiza e que sabe quais arquivos deseja comitar, você está pronto(a). Primeiro comite localmente:

Agora envie seu trabalho: git push. Um registro de transação de todos os commits que compõem o envio será enviado por correio eletrônico para a lista de discussão <lfs-book@lists.linuxfromscratch.org>, de forma que outros(as) editores(as) possam ver imediatamente o que você fez. As mensagens de correio eletrônico de commits contém algumas informações básicas (registro, mudanças para quais arquivos), incluindo uma saída no formato diff -u.

Acerca das mensagens de registro: Devido à maneira como o git log exibe mensagens de registro, por favor, mantenha o tamanho de cada linha abaixo de setenta e dois (72) caracteres. Uma boa mensagem de commit é composta de um sumário curto (não mais que cinquenta caracteres); uma linha em branco; então detalhes, razões, etc. em linhas de menos que setenta e dois (72) caracteres. As mensagens de registro nunca deveriam estar vazias. Ainda que a mensagem seja apenas 'pequeno conserto de erro de digitação', isso servirá. Outras mensagens usuais são 'atualização para o pacote-x.y.z' ou 'consertadas as instruções de instalação do pacote foo'. Essa última usualmente também precisa de linhas de esclarecimento conforme dito acima.

Exemplo: Se você modificou o general.ent; o registro das mudanças; e consertou um erro de digitação na instalação do bash do capítulo 6, [então] o fluxo de trabalho poderia ser:

git add general.ent chapter01/changelog.xml chapter06/bash.xml
git commit -m 'consertado um erro de digitação no bash do capítulo 6'

A parte final de atualizar o livro é atualizar o bilhete. Isso usualmente é tão fácil quanto ir para a wiki (https://wiki.linuxfromscratch.org/lfs); ir ao bilhete e escolher resolver, mudando a resolução para consertado.

Este capítulo cobre as coisas que você precisa fazer quando estiver usando o Trac para registrar defeitos novos no sistema e consertando/atualizando defeitos excepcionais.

Nós assumimos que você já se logou no Trac antes de fazer qualquer coisa delineada nas seções seguintes.

Você encontrou um defeito ou outra pessoa encontrou um defeito e você decidiu adicioná-lo ao Trac. Ou você quer registrar uma solicitação para uma característica que alguma pessoa tenha pedido ou uma tarefa de algum outro tipo.

Quando você estiver pronto(a) para começar a trabalhar em um problema que esteja no Trac, o passo um é vinculá-lo a você próprio(a). Isso informa a todos(as) os(as) editores(as) que você está trabalhando no problema.

Tão logo você tenha consertado um problema e tenha comitado as mudanças relevantes no repositório Subversion, você precisa sinalizar o tíquete como consertado no Trac.

Atualizar um pacote no Livro LFS consiste do seguinte:

Quando um pacote novo é lançado pelos(as) mantenedores(as) dele, nós sinalizamos isso no Trac. Você não precisa atualizar o livro pouco depois que um pacote for lançado, porém ao menos anunciá-lo.

Quando você for atualizar o livro para adicionar um pacote novo a ele, aqui está como você faz isso:

Agora que você está pronto(a), tenha a certeza de que o livro renderiza adequadamente e verifique os links no Capítulo 3 para ter a certeza de que os links do pacote novo são válidos.

Se isso der certo, então você está pronto(a) com a atualização do pacote. Para mais informação acerca de como construir os arquivos HTML a partir dos fontes do livro, consulte o Capítulo 8.

Comite as suas mudanças para o repositório do Git.

Em ambos LFS e BLFS nós tentamos avisar ao(à)s nossos(as) usuários(as) das vulnerabilidades de segurança. As vezes, vulnerabilidades são mencionadas em um anúncio de lançamento; outras vezes elas são divulgadas posteriormente.

Os avisos atuais apontam para os livros de desenvolvimento, com os avisos anteriores apontando para os livros numerados (em vez de 'estáveis'). Provavelmente você precisará criar alguns links simbólicos onde quer que você renderize os livros para que ambas as versões dos livros LFS e BLFS atuais apontem para suas cópias locais, de forma que você possa verificá-las antes de enviar. Se você tiver renderizações locais dos livros lançados atualmente, [então] também poderá criar um link para eles. Como consolidated.html está localizado no livro BLFS, você precisará criar um link simbólico especial para chegar a ele a partir dos seus avisos locais do LFS.

Por razões históricas, os links no rivendell apontam para 'svn' e 'systemd' para os livros atuais.

Normalmente, emitiremos um aviso de segurança assim que tivermos uma correção testada no livro apropriado (LFS ou BLFS), ou seja, uma versão mais recente ou um patch. No entanto, as vezes, uma vulnerabilidade permanece aberta por muito tempo e nós talvez optemos por sugerir uma solução alternativa, como "não use essa característica do pacote".

Nós tentamos fornecer detalhes suficientes para habilitar os(as) usuários(as) a decidirem se precisam atualizar o mais rápido possível, incluindo uma avaliação de vulnerabilidade e quaisquer detalhes que possamos encontrar. Se o(a) desenvolvedor(a) fornecer uma avaliação da gravidade, [então] normalmente usaremos essa. Do contrário, precisamos procurar por aí por detalhes. Se os detalhes de um CVE estiverem visíveis publicamente, [então] existiria uma classificação em https://nvd.nist.gov/vuln/search, apesar de, as vezes, esse sítio rotular os problemas como Moderados quando uma classificação de Alta seria apropriado. Se em dúvida, [então] nossa classificação padrão é Alta.

Na teoria, um(a) usuário(a) de uma versão anterior recente do livro pode examinar nossas vulnerabilidades atuais e anteriores e ver cada vulnerabilidade corrigida a qual afeta um pacote. Na prática, nem sempre fica claro que uma versão mais recente corrigiu a vulnerabilidade - se isso vier à tona depois que tenhamos feito um lançamento com uma versão mais recente do pacote, [então] tais itens seriam ignorados na presunção de que a maioria dos(as) usuários(as) já consultou as vulnerabilidades anteriores e é improvável que note adições novas - por exemplo, uma vulnerabilidade no flac-3.2 foi corrigida no flac-3.3, porém não mencionada publicamente. Em tais casos, nós podemos adicionar uma seção 'Avisos Tardios' entre os avisos para o livro atual e os avisos anteriores - veja-se 10.0-102 no consolidated.html e a entrada correspondente no 10.0.html. Nesses casos, a melhor maneira para alertar os(as) usuários(as) é a de anunciar o aviso nas listas lfs-support e blfs-support.

De tempos em tempos, nós talvez fiquemos cientes de que os detalhes de um aviso deveriam ser mudados, por exemplo, aconteceria de ele ser inválido por alguma razão (por exemplo, nunca em uma versão lançada; ou aplicável somente ao Windows). Quando isso acontecer, nós podemos modificar o item existente e mudar a entrada 'Data' para 'Atualizado' com a data atual.

Para atualizações diárias dos avisos, os arquivos estão organizados em:

Existem duas partes para se criar um aviso:

Grande parte de qualquer item novo será copiado a partir de um modelo ou a partir de um aviso anterior. É importante investir tempo quando revisar o que você criou, para ver se ele lê e vincula corretamente.

A página consolidada fornece uma lista dos nossos avisos desde que começamos a criá-los. Eles são numerados dentro dos lançamentos, em cada caso os mais recentes primeiro. Essa página existe em blfs/advisories, porém ela é comum a ambos LFS e BLFS.

Crie os detalhes para o próximo número de aviso disponível. A parte do topo da página contém um monte de itens comentados os quais podem ser usados como um modelo, porém se existirem avisos anteriores para esse pacote, [então] talvez seja mais fácil copiar os detalhes a partir de um daqueles.

Bem como o número, e o link sa-NN.N-nnn, cada entrada tem uma data e uma gravidade. Onde o(a) desenvolvedor(a) tenha atribuído uma gravidade, normalmente vamos com essa. Se uma fonte tal como NVD tenha atribuído uma gravidade, [então] considere se ela é apropriada (nosso padrão é 'Alta' mesmo para Negação de Serviço em aplicativos não servidor).

Onde um ou mais CVEs tenham sido divulgados, talvez seja útil vincular ao NVD se isso fornecer detalhes; ou, do contrário, a qualquer outra fonte confiável a qual explique a vulnerabilidade (isto é, Google para ela). Se os detalhes não estiverem públicos, [então] você não estaria apto(a) a encontrar um link externo apropriado. Porém, para pacotes os quais fornecem seus próprios avisos, é bom vincular a eles.

Renderize a página, verifique se os links (externos para aplicativos; e internos para os livros sysv e systemd) funcionam corretamente e que o que você escreveu e colou faz sentido.

Seria benéfico confirmar a mudança para consolidated.html neste ponto, de forma que a titularidade da propriedade do número do aviso seja sua (por exemplo, se você pensa que outra pessoa talvez esteja também atualizando avisos). Nesse caso, provavelmente é melhor fazer somente um se você tiver vários; e, então, atualizar a página para o lançamento atual.

Existem páginas separadas para o LFS e para o BLFS onde nós listamos nossos avisos desde nosso lançamento anterior. Essas páginas estão em ordem alfabética, com os avisos mais recentes vindo antes dos mais antigos para o mesmo pacote.

Em ambos LFS e BLFS, a página é rotulada com o número do nosso lançamento atual, de forma que 10.1.html a partir de março de 2021 até que lancemos nossa próxima versão.

Você verá que existe uma <h3>Nome do Pacote<h3> comentada como um guia. A linha <h4> deveria ser copiada a partir da entrada que você criou no consolidated.html. Siga isso com um parágrafo curto sumarizando o problema e como corrigi-lo (ou, em casos excepcionais, outras ações para contornar o problema). Adicione uma frase vinculando ao aviso no consolidated.html.

Alguns pacotes obtém informação extra, por exemplo, o Thunderbird tem um parágrafo itálico explicando como as vulnerabilidades são em um contexto semelhante a navegador. Se esse for o primeiro aviso para o Thunderbird neste lançamento, [então] copie essa parte a partir dos avisos anteriores. Similarmente, no LFS, o glibc obtém informação diferente, pois o único caminho de atualização suportado no LFS é construir um LFS novo: dê a informação e deixe que os(as) usuários(as) decidam o quão séria(s) é(são) a(s) vulnerabilidade(s) para o caso de uso deles(as) (muitas são bastante antigas).

Quando um lançamento novo dos livros está pronto (isto é, os diretórios novos do livro para esta versão tendo sido povoados), existem observações nos arquivos Notes-re-release.txt:

Bem como para atualizar o index.html para o lançamento novo, e criar uma página nova para a versão nova - inicialmente declarando que "Não existem vulnerabilidades de segurança conhecidas" - os avisos para o que é, agora, o lançamento anterior precisam ser corrigidos.

Isso é porque os pacotes naquele lançamento foram testados para as versões e pacotes naquele lançamento, e, de tempos em tempos, os pacotes serão descartados; ou serão substituídos por versões bifurcadas; ou mesmo movidos para uma parte diferente do livro. Assim, os links deveriam ser mudados, de forma que, em vez de apontarem para o livro de desenvolvimento, eles agora apontem para a versão que nós lançamos recentemente.

Este capítulo descreve os processos acerca de como converter os fontes XML do DocBook para HTML, os quais são apresentados para os(as) usuários(as) no sítio da web. Os processos são basicamente os mesmos em uma máquina local quando o(a) usuário(a) clona os XMLs para um repositório local e quer criar os arquivos HTML lá.

Os pré-requisitos são um conjunto pequeno de ferramentas, nomeadamente make; DocBook XML; DocBook XSLT; e as ferramentas xsltproc. Essas ferramentas são usadas para converter XML do DocBook para outros formatos; o formato alvo mais usado é o HTML, o qual pode ser usado para apresentar os livros de uma maneira formatada bem legal para o(a) usuário(a). Outros formatos seriam PDF, porém esse não é parte deste capítulo.

Este capítulo está dividido nas seguintes partes: