From edd659bc46a4d2cb6b2833602330eacdff7068a6 Mon Sep 17 00:00:00 2001 From: Paul W. Frields Date: Apr 12 2018 19:39:47 +0000 Subject: [PATCH 1/2] Rework first part of introduction Signed-off-by: Paul W. Frields --- diff --git a/content/en-US/introduction.adoc b/content/en-US/introduction.adoc index 943febe..9537314 100644 --- a/content/en-US/introduction.adoc +++ b/content/en-US/introduction.adoc @@ -1,80 +1,41 @@ :Tags: joining :Slug: introduction-to-packaging -= Packaging: what, why and how += Introduction to Packaging == What is packaging? -There are a miriad of software being developed and worked on on a daily basis, -each of these come with instructions on how to install them. - -These instructions can be very simple or very complex depending on the software, -its dependencies and simply the complexity of the application. -Packaging is the process of standardizing the different installation method of -all these application into a common format allowing the users to discover, -install and audit their system in a consistent manner. - -In Fedora, the default packaging format is RPM but there are other format -supported such as containers and modules. - -Regardless on the format, packaging comes down to providing to a build systems -some metadata about the application, such as its name, its version, its license -for example as well as instruction on how to build and install the software. - - -== Why do we package? - -// I think I put all the ideas I had in this paragraph but it likely needs to be -// reworked/reworded by someone better in english or maybe once I'm less sleepy - -We have already slightly touched on this question in the paragraph above but -this is important enough to dive into it a little more. - -Using a package allow the administrator of a system to discover, install and -audit the system. There dozens and more ways to install a software, it can -depend on the tools used by the developer (autotool, cmake, qmake...), the -programming language used since all of them come in with their own way to -install libraries from their ecosystem, for example python has `easy_install` -and `pip install`, perl has `cpan install`, R has `R CMD INSTALL` and -`install.packages()`, PHP has `pecl install`, Java has `maven` and so on... -So if a person wants to install an application in any of these languages, they -will have to learn how to use all of these tools. - -The multiplicity of these tools can also easily break systems or other -application if, for example, installing a library overwrites a file used by -another application. - -These tools most often allow to install, remove, potentially update a library or -an extension but do not track the state of the system or do not offer a way to -find out where a file on a system is coming from. So without packaging, for -example, an administrator has no way to audit a system and figure out if a file -is a legitimate file installed by one of the library used by the system or if -the machine has been compromised and the file was installed by the attacker. - -It is also most common that these language-specific library management tool only -support dependencie resolution in the language. So if you are installing a php -library using `pecl`, if that library only depends on other php modules it will -work fine but if it also depends on libraries from another language or libraries -that needs to be installed on the system, `pecl` will not support that and the -installation will fail. - -Not relying on packaging also makes the user's life harder as to keep the system -up to date, they will need to interact with all of these systems while packaging -allows to reduce this to a single application the package manager. - -Some software needs to be compiled before they can be executed, compiling -them will require having a compiler installed but this compiler is most often -not required to run the program and thus having it installed on the system is -not necessary outside of the build. The compiler is one of many example, it is -pretty common that software have different requirement to be built than they -have for running it. Packaging formats allow to make this distinction, the build -requirement will be installed for the build step while the dependencies for -running will be dragged in while installing the package. - -Finally, packages provided by Fedora are built on secure builders, signed by the -release engineering and thus give users a certain guarantee of reproducibility -on the builds as well as that the package installed is coming from Fedora and -has not been altered by a, potentially ill-intented, third party. +There are myriad software projects being developed on a daily basis. +Each of these comes with instructions on how to install. +These instructions can be simple or complex, depending on the nature of the software and its dependencies. +Packaging is the process of standardizing these different installation methods into a common format. + +In Fedora, the default packaging format is RPM, but other formats are supported, such as containers and modules. + +Regardless of the format, packaging also provides metadata about the application to a build system, such as: + +* name +* version +* license +* build and installation instructions + +== Why is packaging useful? + +Standard packaging allows users to discover, install, and audit the software on their system in a consistent way. +There are many ways to build software, and the method often depends on the tools used by the developers. +Similarly, there are many ways to install that software, often depending on the programming language used to write the source code. +For instance, Python has `easy_install` and `pip_install`, Perl has `cpan install`, Java has `maven`, and so on. +The multiplicity of these tools can also easily break systems or other applications if, for example, installing a library overwrites a file used by another application. + +Packaging has numerous advantages over disparate build and language-specific management tools: + +* Packaging tracks system state and makes it easy for an administrator to audit the system to see if files are legitimate and authentic. +* Unlike language-specific tools, packaging tools can resolve dependencies across languages, such as a PHP library that depends on non-PHP content. +* The system owner only has to learn to use one set of tools to install applications, libraries, and other content, regardless of language or build tooling. +* The system need not have a functioning compiler, much less multiple compilers across different languages. + +Packages provided by Fedora are built on secure builders and cryptographically signed. +Therefore they provide users a certain amount of security, reproducibility, and authenticity. == how to package? From 073d256443121c4021249b85815f26d0fd040ad4 Mon Sep 17 00:00:00 2001 From: Paul W. Frields Date: Apr 12 2018 20:54:37 +0000 Subject: [PATCH 2/2] Finish introduction reworking Signed-off-by: Paul W. Frields --- diff --git a/content/en-US/introduction.adoc b/content/en-US/introduction.adoc index 9537314..de1ef79 100644 --- a/content/en-US/introduction.adoc +++ b/content/en-US/introduction.adoc @@ -32,33 +32,31 @@ Packaging has numerous advantages over disparate build and language-specific man * Packaging tracks system state and makes it easy for an administrator to audit the system to see if files are legitimate and authentic. * Unlike language-specific tools, packaging tools can resolve dependencies across languages, such as a PHP library that depends on non-PHP content. * The system owner only has to learn to use one set of tools to install applications, libraries, and other content, regardless of language or build tooling. -* The system need not have a functioning compiler, much less multiple compilers across different languages. +* The system does not need a functioning compiler, much less multiple compilers across different languages. Packages provided by Fedora are built on secure builders and cryptographically signed. Therefore they provide users a certain amount of security, reproducibility, and authenticity. -== how to package? +== How is packaging done? -Fedora supports different packaging formats. We will not go here in the details -of each of them but point you to the places where you can find more -documentation about them. +Fedora supports several different packaging formats. +This document provides an overview of each and references to more documentation about each. === RPMs -RPM is a pre-built binary format of packages. It is built from a `spec` file -containing metadata about the application as well as build instructions. The -spec file is a simple text file with some defined section. -The spec file, together with the sources of the application and eventual patch -can be integrated into a single archive by rpm which is called the source rpm. +RPM is a pre-built, binary package format. +The RPM package is built from source using a `spec` file that contains metadata about the application and build instructions. +The spec file is a simple text file documented in this https://rpm-packaging-guide.github.io/[RPM Packaging Guide]. +Often the spec file, the source code of the application, any patches, and additional files are combined in a single archive called the source rpm or SRPM. -Once the source rpm is built, it results in a single archive containing the -resulting binary files in the same structure as they should appear on the file -system. The archive may also contain some scripts executed before or after the -installation of the application. +The RPM package can be built from the SRPM. +The resulting RPM package file is a single archive that contains the resulting binary files in the same structure as they should appear on the file system. +The archive may also contain scripts executed before or after the installation, update, or removal of the application. === Containers +Documentation on package and build containers is coming soon. + === Modules -Documentation on how to package and build modules is being worked on. We will -update this page when this documentation is published. +Documentation on how to package and build modules is coming soon.