From dba95a1ba44e072583d30ca106d3529c81147ee5 Mon Sep 17 00:00:00 2001 From: Tibbs Date: Sep 08 2018 17:56:50 +0000 Subject: Move text about allowed packages to a separate page. Packaging:What_Can_Be_Packaged --- diff --git a/Packaging:Guidelines.mw b/Packaging:Guidelines.mw index 27bbf50..b28c586 100644 --- a/Packaging:Guidelines.mw +++ b/Packaging:Guidelines.mw @@ -22,92 +22,17 @@ If, in a guideline, the language "should" or "is suggested" is used and it is no Where the language "must", "is required to" or "needs to" is used, the packager may deviate from the guideline only with approval from the packaging committee. Please follow the procedure at ​the [[Packaging_Committee#Bringing_Issues_to_the_Committee|Packaging Committee]] page for making these requests. +== Allowed Packages == +Please review [[Packaging:What_Can_Be_Packaged]] to ensure that what is to be packaged is allowed in Fedora. + == Naming == You should go through the [[Packaging:NamingGuidelines]] to ensure that your package is named appropriately. == Version and Release == Documentation covering the proper way to use the Version and Release fields can be found here: [[Packaging:Versioning]] -== Legal == -There are various legal concerns to consider when packaging for Fedora. - -=== Licensing === -You should review [[Licensing:Main]] and the [[Packaging:LicensingGuidelines]] to ensure that your package is licensed appropriately. - -=== Code Vs Content === -It is important to make distinction between computer executable code and content. -While code is permitted (assuming, of course, that it has an open source compatible license, is not legally questionable, etc.), only some kinds of content are permissable. - -The rule is this: - -If the content enhances the OS user experience, then the content is OK to be packaged in Fedora. This means, for example, that things like: fonts, themes, clipart, and wallpaper are OK. - -Content still has to be reviewed for inclusion. It must have an open source compatible license, must not be legally questionable. In addition, there are several additional restrictions for content: -* Content must not be pornographic, or contain nudity, whether animated, simulated, or photographed. There are better places on the Internet to get porn. -* Content should not be offensive, discriminatory, or derogatory. If you're not sure if a piece of content is one of these things, it probably is. -* All content is subject to review by FESCo, who has the final say on whether or not it can be included. - -Some examples of content which is permissable: - -* Package documentation or help files -* Clipart for use in office suites -* Background images (non-offensive, discriminatory, with permission to freely redistribute) -* Fonts (under an open source license, with no ownership/legal concerns) -* Game levels are not considered content, since games without levels would be non functional. -* Sound or graphics included with the source tarball that the program or theme uses (or the documentation uses) are acceptable. -* Game music or audio content is permissible, as long as the content is freely distributable without restriction, and the format is not patent encumbered. -* Example files included with the source tarball are not considered content. - -Some examples of content which are not permissable: - -* Comic book art files -* Religious texts -* mp3 files (patent encumbered) - -If you are unsure if something is considered approved content, ask on fedora-devel-list. - -=== Packages which are not useful without external bits === -Some software is not functional or useful without the presence of external code dependencies in the runtime operating system environment. When those external code dependencies are non-free, legally unacceptable, or binary-only (with the exception of permissible firmware), then the dependent software is not acceptable for inclusion in Fedora. If the code dependencies are acceptable for Fedora, then they should be packaged and included in Fedora as a pre-requisite for inclusion of the dependent software. Software which downloads code bundles from the internet in order to be functional or useful is not acceptable for inclusion in Fedora (regardless of whether the downloaded code would be acceptable to be packaged in Fedora as a proper dependency). - -This also means that packages which are not functional or useful without code or packages from third-party sources are not acceptable for inclusion in Fedora. - -== No External Kernel Modules == -At one point (pre Fedora 8), packages containing "addon" kernel modules were permitted. This is no longer the case. Fedora strongly encourages kernel module packagers to submit their code into the upstream kernel tree. - -The reference documentation on how to package kernel modules in the "kmod" style has been preserved [[Obsolete/KernelModules|here]] . - -== No inclusion of pre-built binaries or libraries == -All program binaries and program libraries included in Fedora packages must be built from the source code that is included in the source package. This is a requirement for the following reasons: -* Security: Pre-packaged program binaries and program libraries not built from the source code could contain parts that are malicious, dangerous, or just broken. Also, these are functionally impossible to patch. -* Compiler Flags: Pre-packaged program binaries and program libraries not built from the source code were probably not compiled with standard Fedora compiler flags for security and optimization. - -Content binaries (such as .pdf, .png, .ps files) are ''not'' required to be rebuilt from the source code. - -If you are in doubt as to whether something is considered a program binary or a program library, here is some helpful criteria: -* Is it executable? If so, it is probably a program binary. -* Does it contain a .so, ,so.#, or .so.#.#.# extension? If so, it is probably a program library. -* If in doubt, ask your reviewer. If the reviewer is not sure, they should ask the Fedora Packaging Committee. - -Packages which require non-open source components to build are also not permitted (e.g. proprietary compiler required). - -When you encounter prebuilt binaries in a package you '''MUST''': - -* Remove all pre-built program binaries and program libraries in %prep prior to the building of the package. Examples include, but are not limited to, *.class, *.dll, *.DS_Store, *.exe, *.jar, *.o, *.pyc, *.pyo, *.egg, *.so, *.swf files. -* Ask upstream to remove the binaries in their next release. - -=== Exceptions === -* Some software (usually related to compilers or cross-compiler environments) cannot be built without the use of a previous toolchain or development environment (open source). If you have a package which meets this criteria, contact the Fedora Packaging Committee for approval. Please note that this exception, if granted, is limited to only the initial build of the package. You may bootstrap this build with a "bootstrap" pre-built binary, but after this is complete, you must immediately increment Release, drop the "bootstrap" pre-built binary, and build completely from source. Bootstrapped packages containing pre-built "bootstrap" binaries must not be pushed as release packages or updates under any circumstances. These packages should contain the necessary logic to be built once bootstrapping is completed and the prebuilt programs are no longer needed. Information about how you should break circular dependencies by bootstrapping can be found here: [[Packaging:Guidelines#Bootstrapping]] -* An exception is made for binary firmware, as long as it meets the requirements documented here: [[Licensing:Main#Binary_Firmware]] -* Some pre-packaged program binaries or program libraries may be under terms which do not permit redistribution, or be affected by legal scenarios such as patents. In such situations, simply deleting these files in %prep is not sufficient, the maintainer will need to make a modified source that does not contain these files. See: [[Packaging:SourceURL#When_Upstream_uses_Prohibited_Code]] - -== Use of pregenerated code == -Often a package will contain code which was itself generated by other code. This often takes the form of configure files or parsing code generated by bison/yacc or lex/flex. - -It is required that the original source files from which the code was generated be included in the srpm. Generally these files are part of the source archive supplied by upstream, but it may be necessary to fetch those files from an upstream source repository and include them in the srpm as separate Source: entries. - -It is preferred, but not required, that the tools used to generate such code be free software and included in Fedora. - -It is suggested, but not required, that such code be regenerated as part of the build process. The means for doing this are entirely specific to the individual package being built, but it may happen automatically if the necessary dependencies are present at build time. +== Licensing == +You should review [[Licensing:Main]] and the [[Packaging:LicensingGuidelines]] to ensure that your package is licensed appropriately and that the license is properly indicated. == Libraries and Applications ==