| |
@@ -1,103 +1,62 @@
|
| |
: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.
|
| |
+ 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 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.
|
| |
+ 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 there are other format
|
| |
- supported such as containers and modules.
|
| |
+ In Fedora, the default packaging format is RPM, but other formats are 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.
|
| |
+ 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 do we package?
|
| |
+ == Why is packaging useful?
|
| |
|
| |
- // 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
|
| |
+ 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.
|
| |
|
| |
- We have already slightly touched on this question in the paragraph above but
|
| |
- this is important enough to dive into it a little more.
|
| |
+ Packaging has numerous advantages over disparate build and language-specific management tools:
|
| |
|
| |
- 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.
|
| |
+ * 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 does not need a functioning compiler, much less multiple compilers across different languages.
|
| |
|
| |
- 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.
|
| |
+ Packages provided by Fedora are built on secure builders and cryptographically signed.
|
| |
+ Therefore they provide users a certain amount of security, reproducibility, and authenticity.
|
| |
|
| |
- 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.
|
| |
+ == How is packaging done?
|
| |
|
| |
- 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.
|
| |
-
|
| |
-
|
| |
- == how to package?
|
| |
-
|
| |
- 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.
|
| |