08.1 (Conspect) Package maintaining

Let's see how we collect the package. It is important to show what specificity of working out of an OS component within the limits as and what should turn out as a result. What experimental means are used that the result appeared acceptable.

We have a distribution that is a collection of a product program + some installer(something to install) = get a working OS.

The idea is to take some software product, which is not yet in the repository, Written in C (preferably), and this software product:

Programmer, mathematician https://www.chiark.greenend.org.uk/~sgtatham/ - here you can read about all the software he collects.

We will specifically work with his creation https://www.chiark.greenend.org.uk/~sgtatham/spigot/ - calculator to which you can set a certain accuracy. Let's try to build a package out of it.

1. Just build this software product as if we just downloaded and compiled it. Where do we build it? There's an option to put on compilers, libraries that the author recommends. But it's dangerous, because it may not be needed and it will 'hang' in the system and interfere with it after we build the package. And of course not the fact that it will be a 'clean' environment. We need to worry about creating an isolated build environment. For instance, we should build a virtual machine there too. Alt Linux developed the 'hasher' technology that doesn't use such powerful tools as virtual machines. Linux has modern isolation mechanisms - chroot.

Creating:

User now builder:

We put in all the necessary packages for us to work comfortably:

Download source from https://www.chiark.greenend.org.uk/~sgtatham/spigot/ :

Note that even the download is from inside the build environment because the network is allowed.

Let's unpack it:

Let's try to put it together:

We see that it has opened up - it's a typical old project with no subdirectories, sources, documentation and so on. The job is not only about technical knowledge, but also about intuition :)

Our program is written in C++. There is no makefile, only makefile.in and makefile.am. makefile.in - means that this set is not just built with make, but with the special 'configure' script that forms this makefile. Makefile - instruction on how to build this binary from source data, if you have all the necessary tools in your system. Configure - generator (in shell language) - checks for tools in the development environment and gives notifications.

Based on the results of Configure work, a makefile will be formed. Let's just run Configure, making sure we've got what we need:

Now he's found everything, it's okay.

As far as we are building a tree of assembly dependencies between the individual parts of our program - walking on the oriented graph you can clearly identify independent tasks.

Making sure there's no warning, then it's okay.

You can test the result.

We're picking up the package

To build a package, you need to build a specfile:

We create in it:

Automatic determination of the dependencies of our package. Special robots push through the directory with freshly installed files from the package to determine what we need for the ability of this package (requires).

And now the package is packed, even three: the source, the RPM and the debuginfo file on order to debug the programme.

The problem of assembly dependencies

The most important thing is to describe what additional packages need to be installed in the system to build it. There is a tool that 'buildreq' starts building a package and tracks which tools were started during the build process, which files were read, and which packages actually own these tools and these files. All of this list will automatically come to us in specfile:

We got a package that will give us a job (if the tests pass). But that's half the story because it's just a package collection and that's all. We still have to put this package in the repository. To put the package in the repository, we need to make sure that it is going to, and then give the source code to a special 'build' with a clean environment.

Publishing a package

Maintaining a package

HSE/ArchitectureOS/08_PackageMaintaining/Conspect_en (последним исправлял пользователь NataliaKrauze 2020-05-17 12:45:00)