Zen

Translation

English type: Plain text
The spec file ("spec") is a fundamental element in the packaging workflow. Any change that is made to the package will include a change to the spec. Because packages in Fedora are maintained by a community of packagers as well as automated tooling, it is important for the specs to follow certain conventions. The bulk of these packaging guidelines involves what goes into a spec, but here are a few general items.
467/4170 · 417

Sign in to save the translation.

English Portuguese (Brazil) Actions
This is because the Fedora logo is a trademark, which are handled under a different legal framework than code. It must only be distributed under terms that protect the trademark. Keeping Fedora trademarks separate in their own package instead of scattered across various other packages is also an essential practice for enabling remixes that necessarily must https://fedoraproject.org/wiki/Legal:Trademark_guidelines#Secondary_Mark[not use the Fedora trademark], and instead roll their own *-logos package or use the generic-logos package.
Isso ocorre porque o logotipo do Fedora é uma marca registrada, que é tratada sob uma estrutura legal diferente do código. Ele deve ser distribuído sob termos que protejam a marca registrada. Manter as marcas registradas do Fedora separadas em seu próprio pacote, em vez de espalhadas por vários outros pacotes, também é uma prática essencial para permitir remixes que necessariamente https://fedoraproject.org/wiki/Legal:Trademark_guidelines#Secondary_Mark[não devem usar a marca registrada do Fedora], e em vez disso, crie seu próprio pacote *-logos ou use o pacote generic-logos.
Libraries and Applications
Bibliotecas e aplicativos
Many language- or domain-specific guidelines refer to "libraries", "modules", "plug-ins" or other terms specific to the language or domain. This is specifically important to package naming. Some applications may include libraries, and some libraries may include applications, so the distinction is not always clear.
Muitas diretrizes específicas de idioma ou domínio referem-se a "bibliotecas", "módulos", "plug-ins" ou outros termos específicos do idioma ou domínio. Isto é especificamente importante para a nomenclatura de pacotes. Alguns aplicativos podem incluir bibliotecas e algumas bibliotecas podem incluir aplicativos, portanto a distinção nem sempre é clara.
Library or Application?
Biblioteca ou aplicativo?
If the primary purpose of a package is to provide executables to be run by users, it SHOULD be packaged as an application. If it also includes libraries which may be imported or linked to by other code, see <<Mixed Use Packages>> below.
Se o objetivo principal de um pacote é fornecer executáveis para serem executados pelos usuários, É RECOMENDADO que ele seja empacotado como um aplicativo. Se também incluir bibliotecas que podem ser importadas ou vinculadas por outro código, consulte <<Pacotes de uso misto>> abaixo.
If the primary purpose of a package is to provide libraries intended to be imported or loaded into other code, it is considered a library and MUST be packaged as such. If it contains utility programs that can be run by users as well, see <<Mixed Use Packages>> below.
Se o objetivo principal de um pacote é fornecer executáveis para serem executados pelos usuários, ele DEVE ser empacotado como um aplicativo. Se também incluir bibliotecas que podem ser importadas ou vinculadas por outro código, consulte <<Pacotes de uso misto>> abaixo.
It is left to the packager to determine the primary purpose of a package. Often times upstream will already have done this with their choice of naming and that choice SHOULD be followed by the Fedora packager.
Cabe ao empacotador determinar o propósito principal de um pacote. Muitas vezes o upstream já terá feito isso com sua escolha de nomenclatura e É RECOMENDADO que essa escolha seja seguida pelo empacotador do Fedora.
Mixed Use Packages
Pacotes de uso misto
Many packages, regardless of their primary purpose, include both applications and libraries. In this case one or both SHOULD be packaged in subpackages in order to allow other applications to depend on only the library and not the associated application(s). Installing an application that depends on a library or service should not automatically pull in other applications associated with that library or service.
Muitos pacotes, independentemente da sua finalidade principal, incluem aplicações e bibliotecas. Neste caso, É RECOMENDADO que um ou ambos sejam empacotados em subpacotes para permitir que outros aplicativos dependam apenas da biblioteca e não do(s) aplicativo(s) associado(s). No caso da instalação de um aplicativo que depende de uma biblioteca ou serviço, NÃO É RECOMENDADO incluir automaticamente outros aplicativos associados a essa biblioteca ou serviço.
Package Independence
Independência do pacote
Packages SHOULD be installable independently whenever this is technically feasible, but they MUST specify dependencies of correct type on other packages if necessary, see <<Dependency Types>> below.
É RECOMENDADO que os pacotes sejam instaláveis de forma independente sempre que isso for tecnicamente viável, mas eles DEVEM especificar dependências do tipo correto em outros pacotes, se necessário, veja <<Tipos de dependência>> abaixo.
Desktop applications MUST NOT depend on other desktop applications unless strictly required. In particular, packages that contain a visible `.desktop` file (a `.desktop` file that does not contain the line `+NoDisplay=true+`) SHOULD NOT have a `Requires`, `Recommends`, or `Supplements` on any other package containing a visible desktop file, directly or indirectly.
Os aplicativos de desktop NÃO DEVEM depender de outros aplicativos de desktop, a menos que seja estritamente necessário. Em particular, pacotes que contêm um arquivo `.desktop` visível (um arquivo `.desktop` que não contém a linha `+NoDisplay=true+`) NÃO DEVEM ter um `Requires`, `Recommends` ou `Supplements` em qualquer outro pacote que contenha um arquivo de desktop visível, direta ou indiretamente.
For example, it would be reasonable for a video game level editor to require the associated video game in order to function, or for an application's plugin to require the associated application. But it would not be reasonable for an application that happens to use a database library to depend on a database management suite associated with that library, or for an application that happens to use a particular programming language to depend on management tools associated with that programming language.
Por exemplo, seria razoável que um editor de níveis de videogame exigisse o videogame associado para funcionar, ou que um plug-in de aplicativo exigisse o aplicativo associado. Mas não seria razoável que um aplicativo que usasse uma biblioteca de banco de dados dependesse de um conjunto de gerenciamento de banco de dados associado a essa biblioteca, ou que uma aplicação que usasse uma linguagem de programação específica dependesse de ferramentas de gerenciamento associadas a essa linguagem de programação.
If a source package provides multiple graphical applications, those applications SHOULD be packaged in separate subpackages when feasible.
Se um pacote fonte fornece múltiplas aplicações gráficas, essas aplicativos DEVEM ser empacotados em subpacotes separados quando possível.
Spec Files
Arquivos spec
The spec file ("spec") is a fundamental element in the packaging workflow. Any change that is made to the package will include a change to the spec. Because packages in Fedora are maintained by a community of packagers as well as automated tooling, it is important for the specs to follow certain conventions. The bulk of these packaging guidelines involves what goes into a spec, but here are a few general items.
O arquivo spec ("spec") é um elemento fundamental no fluxo de trabalho de empacotamento. Qualquer alteração feita no pacote incluirá uma alteração nas especificações. Como os pacotes no Fedora são mantidos por uma comunidade de empacotadores e também por ferramentas automatizadas, é importante que as especificações sigam certas convenções. A maior parte dessas diretrizes de empacotamento envolve o que consta nas especificações, mas aqui estão alguns itens gerais.
Spec File Naming
Nomenclatura do arquivo spec
The spec file MUST be named `+%{name}.spec+`. That is, if your package is named `+example+`, the spec file must be named `+example.spec+`.
O arquivo spec DEVE ser nomeado `+%{name}.spec+`. Ou seja, se o seu pacote for denominado `+exemplo+`, o arquivo spec deverá ser denominado `+exemplo.spec+`.
Spec Legibility
Legibilidade do spec
All spec files MUST be legible and maintained in such a way that the community of packagers is able to understand and work with them.
Todos os arquivos spec DEVEM ser legíveis e mantidos de tal forma que a comunidade de empacotadores seja capaz de entendê-los e trabalhar com eles.
To help facilitate legibility, only macros and conditionals for Fedora and EPEL are allowed to be used in Fedora Packages. Use of macros and conditionals for other distributions, including Fedora derivatives, is not permitted in spec files of packages in the main Fedora repositories unless those macros and conditionals are also present in Fedora.
Para ajudar a facilitar a legibilidade, apenas macros e condicionais para Fedora e EPEL podem ser usadas em Pacotes Fedora. O uso de macros e condicionais para outras distribuições, incluindo derivados do Fedora, não é permitido em arquivos de especificações de pacotes nos principais repositórios do Fedora, a menos que essas macros e condicionais também estejam presentes no Fedora.
Spec File Encoding
Codificação de arquivos spec
Unless you need to use characters outside the https://commons.wikimedia.org/wiki/File:Ascii_full.png[ASCII repertoire], you will not need to be concerned about the encoding of the spec file. If you do need non-ASCII characters, save your spec files as UTF-8. If you're in doubt as to what characters are ASCII, please refer to https://commons.wikimedia.org/wiki/File:Ascii_full.png[this chart].
A menos que você precise usar caracteres fora do https://commons.wikimedia.org/wiki/File:Ascii_full.png[repertório ASCII], você não precisará se preocupar com a codificação do arquivo spec. Se você precisar de caracteres não ASCII, salve seus arquivos de especificações como UTF-8. Se você tiver dúvidas sobre quais caracteres são ASCII, consulte https://commons.wikimedia.org/wiki/File:Ascii_full.png[este gráfico].
Non-ASCII Filenames
Nomes de arquivos não ASCII
Similarly, filenames that contain non-ASCII characters must be encoded as UTF-8. Since there's no way to note which encoding the filename is in, using the same encoding for all filenames is the best way to ensure users can read the filenames properly. If upstream ships filenames that are not encoded in UTF-8 you can use a utility like convmv (from the convmv package) to convert the filename in your %install section.
Da mesma forma, nomes de arquivos que contenham caracteres não ASCII devem ser codificados como UTF-8. Como não há como saber em qual codificação o nome do arquivo está, usar a mesma codificação para todos os nomes de arquivos é a melhor maneira de garantir que os usuários possam ler os nomes dos arquivos corretamente. Se o upstream enviar nomes de arquivos que não estão codificados em UTF-8, você poderá usar um utilitário como convmv (do pacote convmv) para converter o nome do arquivo em sua seção %install.
Spec Maintenance and Canonicity
Manutenção dos spec e canonicidade
Fedora's git repository is the canonical location for Fedora spec files. Maintainers MUST expect that other maintainers and automated tooling will make changes to their packages, potentially without communicating prior to doing so (though communication is always encouraged). If some maintainers are also attempting to keep copies of a spec in an outside repository, they MUST be prepared to merge changes made to the spec in Fedora's repository, and MUST NOT overwrite those changes with a copy from an external repository or using `+fedpkg import+`.
O repositório git do Fedora é o local canônico para os arquivos de especificações do Fedora. Os mantenedores DEVEM esperar que outros mantenedores e ferramentas automatizadas façam alterações em seus pacotes, potencialmente sem se comunicarem antes de fazê-lo (embora a comunicação seja sempre incentivada). Se alguns mantenedores também estão tentando manter cópias de uma especificação em um repositório externo, eles DEVEM estar preparados para mesclar as alterações feitas na especificação no repositório do Fedora e NÃO DEVEM sobrescrever essas alterações com uma cópia de um repositório externo ou usando `+fedpkg import+`.
Source File Verification
Verificação de arquivo-fonte
Where the upstream project publishes OpenPGP signatures of their releases, Fedora packages *SHOULD* verify that signature as part of the RPM build process.
Nos casos em que o projeto upstream publica assinaturas OpenPGP de seus lançamentos, *É RECOMENDADO* que os pacotes Fedora verifiquem essa assinatura como parte do processo de construção do RPM.
Although a checksum in the sources file certifies that a file retreived from the lookaside cache is the one that the packager uploaded, it is silent on whether the file is what the upstream project released. A signature by the upstream developers certifies that the source is identical to what they released. Verifying the signature as part of the build ensures that packagers don't forget to verify it.
Embora uma soma de verificação no arquivo-fonte certifique que um arquivo recuperado do cache _lookaside_ é aquele que o empacotador carregou, ela não informa se o arquivo é o que o projeto upstream lançou. Uma assinatura dos desenvolvedores originais certifica que a fonte é idêntica à que eles lançaram. A verificação da assinatura como parte da construção garante que os empacotadores não se esqueçam de verificá-la.
Obtaining the Correct Keys
Obtendo as chaves corretas

Loading…

User avatar rffontenelle

Translation added
The spec file ("spec") is a fundamental element in the packaging workflow. Any change that is made to the package will include a change to the spec. Because packages in Fedora are maintained by a community of packagers as well as automated tooling, it is important for the specs to follow certain conventions. The bulk of these packaging guidelines involves what goes into a spec, but here are a few general items.
O arquivo spec ("spec") é um elemento fundamental no fluxo de trabalho de empacotamento. Qualquer alteração feita no pacote incluirá uma alteração nas especificações. Como os pacotes no Fedora são mantidos por uma comunidade de empacotadores e também por ferramentas automatizadas, é importante que as especificações sigam certas convenções. A maior parte dessas diretrizes de empacotamento envolve o que consta nas especificações, mas aqui estão alguns itens gerais.
a year ago
Browse all string changes

Things to check

Consecutive duplicated words

Text contains the same word twice in a row: spec

Reset

Glossary

English Portuguese (Brazil)
guidelines diretrizes fedora-docs-l10n/packaging-guidelines
packaging empacotamento fedora-docs-l10n/packaging-guidelines
spec file arquivo spec fedora-docs-l10n/packaging-guidelines

RPM 'spec' file

8884669 String information

Source string description
type: Plain text
Source string location
pages/index.adoc:219
String age
3 years ago
Last updated
a year ago
Source string age
3 years ago
Translation file
po/pt_BR/master/pages/index.po, string 43