OpenSource in action
Very often in the network you can find lengthy arguments about the undoubted benefits of open source software, about the motivation of programmers involved in similar projects, and so on. In addition, the fact that any user of such software with certain technical skills will be able to “sharpen” all this stuff for themselves is especially noted. Say, it's not for nothing that the source code is open.
However, personally, I know very few people (to be honest, only two) who at least enjoyed the benefits of the open source code of the programs they use. The main arguments are: I do not know where this very code should be taken; I do not know how to collect all this later; I'm afraid to make a garbage bin out of my distribution kit, collecting my own modules.
In this small article I will try to give a simple example of how you can modify something, while maintaining a harmonious package and repository distribution structure.
')
To illustrate all the techniques and mechanisms, I set myself a goal that is quite easy to accomplish, but has no practical value: I have the frequently used wget utility and I’m bleeding from the nose, as I want it to greet me every time I start. Here I want and that's it. To this we will strive.
Since I carried out all the manipulations described below on my home distribution (Fedora), we will consider utilities and commands related to this particular build. In other systems there will be differences (deb instead of rpm, aptitude instead of yum), but we are mostly interested in the methodology, not the details.
To work, we need the installed packages yum-utils and rpm-build.
So, first we need to decide which package our executable file belongs to:
Yeah, our package is called “wget”. Now we need its source codes. In addition to binary packages, source packages are usually stored in repositories, so we don’t need to search for anything anywhere. It is enough to use the built-in tools:
After executing this command, an rpm-package will appear in the current directory, containing the source codes of interest to us of the version we are interested in. It must be installed:
All further actions will take place in the '/ root / rpmbuild' folder, which will automatically be created when installing the source package. It is there, in the subfolder 'SOURCES', we will find the archive with the source code 'wget-1.11.4.tar.bz2' directly. Next thing is the technique: unpack the archive, find the file 'main.c', in the main function, make the changes of interest to us (add the desired printf), and, attention, pack everything back into the archive with the same name. We will not build a separate module - we are interested in the package as a whole, because this is correct. There are no 'make && make install', after which you will not find the ends, only packages, especially since all the infrastructure necessary for this is already prepared. Things are a little less - go to the '/ root / rpmbuild / SPECS' directory and execute:
The rpmbuild utility will build the binary modules itself and pack everything into a single package. It acts in accordance with the .spec file, so that at this stage it is possible to make changes: add or remove any files from the package, modify installation scripts, and so on. The mechanism has a certain flexibility.
Total output in the folder '/ root / rpmbuild / RPMS' we get a package, ready either for immediate installation in our system, or for further distribution among the owners of delusions of grandeur who like us and greet them with their utilities.
As a continuation of the topic, it is possible to write a patch (by the way, examples of patches can be viewed in the source directory) automating the assembly of the package with the functionality we need in future versions, and it is possible to prohibit further updating of this package in general if it suits us. The case is master's.
However, personally, I know very few people (to be honest, only two) who at least enjoyed the benefits of the open source code of the programs they use. The main arguments are: I do not know where this very code should be taken; I do not know how to collect all this later; I'm afraid to make a garbage bin out of my distribution kit, collecting my own modules.
In this small article I will try to give a simple example of how you can modify something, while maintaining a harmonious package and repository distribution structure.
')
To illustrate all the techniques and mechanisms, I set myself a goal that is quite easy to accomplish, but has no practical value: I have the frequently used wget utility and I’m bleeding from the nose, as I want it to greet me every time I start. Here I want and that's it. To this we will strive.
Since I carried out all the manipulations described below on my home distribution (Fedora), we will consider utilities and commands related to this particular build. In other systems there will be differences (deb instead of rpm, aptitude instead of yum), but we are mostly interested in the methodology, not the details.
To work, we need the installed packages yum-utils and rpm-build.
So, first we need to decide which package our executable file belongs to:
[root@phantomazz ~]$ rpm –qf `which wget`
wget-1.11.4-3.fc11.x86_64
Yeah, our package is called “wget”. Now we need its source codes. In addition to binary packages, source packages are usually stored in repositories, so we don’t need to search for anything anywhere. It is enough to use the built-in tools:
[root@phantomazz ~]$ yumdownloader --source wget
After executing this command, an rpm-package will appear in the current directory, containing the source codes of interest to us of the version we are interested in. It must be installed:
[root@phantomazz ~]$ rpm –ivh wget-1.11.4-3.fc11.src.rpm
All further actions will take place in the '/ root / rpmbuild' folder, which will automatically be created when installing the source package. It is there, in the subfolder 'SOURCES', we will find the archive with the source code 'wget-1.11.4.tar.bz2' directly. Next thing is the technique: unpack the archive, find the file 'main.c', in the main function, make the changes of interest to us (add the desired printf), and, attention, pack everything back into the archive with the same name. We will not build a separate module - we are interested in the package as a whole, because this is correct. There are no 'make && make install', after which you will not find the ends, only packages, especially since all the infrastructure necessary for this is already prepared. Things are a little less - go to the '/ root / rpmbuild / SPECS' directory and execute:
[root@phantomazz ~]$ rpmbuild -bb wget.spec
The rpmbuild utility will build the binary modules itself and pack everything into a single package. It acts in accordance with the .spec file, so that at this stage it is possible to make changes: add or remove any files from the package, modify installation scripts, and so on. The mechanism has a certain flexibility.
Total output in the folder '/ root / rpmbuild / RPMS' we get a package, ready either for immediate installation in our system, or for further distribution among the owners of delusions of grandeur who like us and greet them with their utilities.
As a continuation of the topic, it is possible to write a patch (by the way, examples of patches can be viewed in the source directory) automating the assembly of the package with the functionality we need in future versions, and it is possible to prohibit further updating of this package in general if it suits us. The case is master's.
Source: https://habr.com/ru/post/77070/
All Articles