From 53a8be5ed5feb2d77ad1848faad70c6fb1c187ff Mon Sep 17 00:00:00 2001 From: Pierre-Yves Chibon Date: Apr 10 2018 02:19:48 +0000 Subject: Start working on the introduction page Signed-off-by: Pierre-Yves Chibon --- diff --git a/content/en-US/introduction.adoc b/content/en-US/introduction.adoc index 0d61f47..4e02d7c 100644 --- a/content/en-US/introduction.adoc +++ b/content/en-US/introduction.adoc @@ -1,9 +1,87 @@ = Packaging: what, why and how -What is packaging -why do we package -how to package (links) - - rpms - - modules - - flatpak - ... +== 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. +In addition, 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. +Similarly, the multiplicity of these tools may also simply break systems if, for +example, installing a library overwrites a file used by another application. +// the `...` below are me missing the ideas on how to start the sentence +... it is 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. +In addition, 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. + +=== RPMs + +=== Containers + +=== Modules + +Documentation on how to package and build modules is being worked on. We will +update this page when this documentation is published.