#13 Rework introduction
Merged 5 years ago by pingou. Opened 5 years ago by pfrields.
fedora-docs/ pfrields/package-maintainer-docs intro-rework  into  master

file modified
+37 -78
@@ -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.

  • Cleaned up for brevity/style
  • Referenced a bigger guide for RPM
  • Reworked for more positive voice

2 new commits added

  • Finish introduction reworking
  • Rework first part of introduction
5 years ago

Space missing between link: and https?

Couple of comments, otherwise :thumbsup: for me

  • "need not have..." is correct English, although "does not need" would also be acceptable.
  • no space missing, the rendering is "found in this RPM Packaging Guide".

2 new commits added

  • Finish introduction reworking
  • Rework first part of introduction
5 years ago

Pull-Request has been merged by pingou

5 years ago
Metadata