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:

• 1) build as a program;
• 2) turn it into a package and place it in the repository.

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

• 1. PuTTY terminal client: https://www.chiark.greenend.org.uk/~sgtatham/putty/ ;

• 2. logic puzzle collection: https://www.chiark.greenend.org.uk/~sgtatham/puzzles/ ;

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:

•    1 hsh —initroot
     2 
  

User now builder:

•    1 hsh-shell
     2 
  

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

•    1 $ mkhasher -v
  

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

•    1 wget https://www.chiark.greenend.org.uk/~sgtatham/spigot-20200101.b1b0b20.tar.gz
     2 
  

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

Let's unpack it:

•    1 tar xvf spigot-20200101.b1b0b20.tar.gz
     2 
  

Let's try to put it together:

•    1 cd spigot-20200101.b1b0b20/
     2 ls 
     3 
  

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:

•    1 hsh-install gcc-c++
     2 hsh-install libgmp-devel libncurses-devel halibut
     3 mkhasher
     4 cd spigot-20200101.b1b0b20/
     5 ./configure
     6 
  

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.

•    1 make -j8
     2 
  

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:

•    1 vim RPM/SPECS/spigot.spec
     2 
  

We create in it:

•    1 Name:        Name
     2 Version number:        20200101
     3 Release(how many times have we collected this package) :        alt1.
     4 Group(''atavism i.e. bc (calculator), and see in which group it is'') :        Science/Mathematics
     5 License :        MIT
     6 Summary(''package description, you need to take from the site'') :        A command-line streaming exact real calculator
     7 URL :        https://www.chiark.greenend.org.uk/''sgtatham/spigot/
     8 Source :        %name-%version.b1b0b20.tar.gz
     9 %description (''long description'') :
    10 
    11 %prep
    12 %setup -n %name-%version.b1b0b20
    13 
    14 %build
    15 %configure
    16 %make_build
    17 
    18 %install
    19 %makeinstall_std
    20 
    21 %check
    22 ''make test''
    23 
    24 %files
    25 %doc %_defaultdocdir/%name
    26 %_binar/*
    27 %_manldir/*
  

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:

•    1 buildreq RPM/SPECS/spigot.spec
     2 
  

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

• Why not just to upload binary?
  • Clean rebuild
  • Repository integrity check

• Why not just to upload source?

  • History, publicity and cooperation
  • But you can do this

• Tending a package git

  • With or without sources?
• Build farm:
  • Access to all source (git/srpms)
  • Access to repository
  • Mass test rebuilds
  • Job control

Maintaining a package

• Searching for updates
• Patches and Sisyphean labour
• Leadership or joint efforts?
• Cumulative tasks participation