Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you solutions to the problem of Linux dependence. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

This paper introduces some alternative methods to violently crack the dependency relationship between RPM and DEB software packages, which is sometimes a way of PUBG for those who can't extricate themselves from the dependency trap. As to whether it is appropriate to do so, it is a matter of opinion, but this tough attitude is commendable. In addition, some of the views in this article only represent the author's understanding and may not be correct.

Recently, I happen to be studying dpkg and rpm, and I have a deeper understanding of Linux dependency.

I have read a lot on the Internet, and all the Docker, virtual machines, compilation and installation, and all kinds of alternative answers are compromises and concessions that we have no time to make in response to the daily heavy business.

And our technology-oriented, "always like the front hard!"

There are many ways to install the dependence problem of hard Linux software. I divide it into two categories!

"one is legal, the other is violence."

Let's start with the legal solution.

It's also a solution that everyone knows:

Sudo apt-get install xxxxx

In general, it is installed with software dependencies. If the dependency installation fails in this process, execute:

Sudo apt-get-f install

Not twice at a time, as long as there is in the source, as long as you can ensure that the dependency is smooth, no matter how many dependencies can be executed several times.

If you can't find it in the source of dependency. The solution is to find the installation package of the missing library and download it manually. Then install it through sudo dpkg-I xxxx.deb.

There are two main ways to find installation packages that need to be downloaded manually:

Baidu search directly for the package name + version number and put the keyword deb

Through the source.

Baidu directly find the library will not say much, talk about how to find through the source.

You search the Internet for ubuntu domestic sources. You'll find a lot of things like this:

Deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ xenial main restricted universe multiverse

This is actually the source address configured for the apt-get tool, and it is also an actual URL, which you can access directly from the browser, such as the one above:

Https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ xenial main restricted universe multiverse

It actually represents the directories main, restricted, universe and multiverse under the path https://mirrors.tuna.tsinghua.edu.cn/ubuntu/pool/xenial/:

The apt-get tool automatically retrieves the corresponding package download and installation in these four directories.

In some special cases, such as when the machine network is limited, but the browser has a proxy that can access the external network. Apt-get cannot get the software from the source. You can manually find the corresponding software package here and download it and install it using dpkg.

For example, here, you can manually find the installation package path of mysql, and then click to download it directly:

I just said that apt-get install can't fix the dependencies, so after you download it manually and package the missing installations, you can put on the packages that you just couldn't install through apt-get.

This is a very reasonable and legal solution.

To add a legal technique, you can try:

Apt-get install native software package

This is because:

Dependency detection and software installation are not done by apt-get, but by dpkg. Dependency does not satisfy the "auto-repair dependency" is what apt-get does.

So, if you download a deb installation package to install through dpkg, but the dependency is not satisfied, he will only prompt you that the dependency is missing, but he will not automatically find and install the dependency, although you can still download and install the missing dependency, if he is missing ten or eight, it is not realistic for you to download it manually and then install it with dpkg.

For example: I downloaded an installation package of Sogou Input here. Dpkg-I cannot be installed, but it can be installed through apt-get install:

Note: when installing local software through apt-get, be sure to write the path, which is absolutely all right, but not just the package name. Otherwise, it will go to the source and will not install it locally.

The above solution can solve almost 80% of the installation dependency problems. To sum up:

To install the software: sudo apt-get install xxxx

Encountered dependency problem: sudo apt-get-f install

If there is a defect that cannot be installed, go online and download what is missing. After downloading it, sudo apt-get install. / xxxx installs the missing package and then installs the original package.

Next, let's talk about the solution to violence.

The reason for violence is that the way I have just done is already the limit of what automated programs provided by tools and systems can do in my opinion.

If there are still problems that cannot be satisfied with dependencies, such as what is about to install xxxx but the current version of the system is higher than xxxx.

In general, in this case, the system no longer advises you to do it. If you have to do it forcefully, it is likely to destroy the existing program dependency structure.

If you are lucky or you have high hands, there is no problem with hard fitting.

Less impact, you installed this software, the other software can not be used or will collapse.

The impact is a little bigger, some system commands do not work, the interface is stuck, the resource manager crashed, and so on.

The impact is a little bigger, there is nothing wrong with the installation and use, after reboot, it is stuck in the loading process, and can no longer enter the system.

"I have encountered all of the above!"

So in the following way, you should learn knowledge or watch me pretend to be forced. If you do it yourself, you still have to be careful. At the very least, don't force it on the servers of client machines and production environments.

Solutions to violence include:

-- ignore-depends, ignoring the reliance on direct installation.

Unpack the installation package, delete the dependent fields and repackage.

Modify the status file recorded in the system.

Ignore the installation failure and run it directly.

Take it directly to the root directory and decompress it on the spot.

Change the dpkg source code and directly do not detect dependencies. One by one said:

1.-- ignore-depends

This is the lowest technical threshold of all violence scenarios, and you can view it through dpkg-- help-- ignore-depends option:

Options:

. Other options

-- ignore-depends=,...

Ignore all dependencies on.

-- force-...

Ignore the problems encountered (see-force-help).

. Other options

This option specifies which dependent packages to ignore. So if the dependency is not satisfied during installation, you can simply add this parameter to ignore the dependency:

Of course, there will be no problem with the installation, but it depends on nature whether it can be used or not.

"it's not that the dependence is not satisfied, and if you install it, you can't use it at all." sometimes it's just incomplete.

For example, if you install a QQ that relies on ffmpeg, you may have no problem installing it directly after you ignore it, but the program will collapse as soon as you click on a video call. (it's hypothetical. I don't know what QQ uses or what.)

Although the threshold of this scheme is low, a fatal flaw is that it is too troublesome. I am short of two, write two ignore parameters. In the process of installation, we often encounter the kind of parameters that are short of ten or eight all of a sudden, and it is really difficult to write such parameters.

2. Unpack the installation package, delete the dependent fields and repackage

This solution can directly and drastically eliminate all the dependencies of the software package, but it requires a little technical background:

"first of all, you have to be able to extract the installation package, and then you have to be able to make the installation package."

Dpkg-X will only extract the files of the installation package, not the script and control information that comes with the installation package.

"right"-> "extract here", the extracted control and data are separated into two compressed packages, and they are not in a perfect state before packaging.

What we need to use here is

Dpkg-deb-R sogoupinyin_xxxx.deb. / sogou

What is unzipped in this way is the complete appearance of deb before it is packaged. I unzipped a Sogou Input installation package as an example:

We don't care about anything else, just open the control file:

See the part of the red box, just kill the whole line. Then type the detached files back into an installation package:

Fakeroot dpkg-deb-- build. / sogou mysogou.deb

The only difference between this self-made mysogou installation package and Sogou's native installation package is that there is no dependency.

This will allow you to go all the way without hindrance and install it directly.

3. Modify the status file recorded in the system

The idea is similar to that just now, except that it has changed to a breakthrough point, which is a little more convenient than just now.

The idea we broke through just now is: there is a dependence on the software recorded in the installation package, and there is no dependence if you kill it all.

Then the idea of this scheme is: if the detection dependency discovery system is not satisfied, we will forge a satisfied dependency environment for him.

The control file we mentioned just now, all deb files are available, and during installation (neither after installation nor before), it is recorded in the: / var/lib/dpkg/status file in the system.

The contents of this file are also the source of information about what the dpkg-l command displays.

As we said above, dependency detection retrieves the source of information in the system that satisfies the dependency.

If the software is uninstalled via dpkg-r, the information in this status file will not be deleted, only the Status field will be changed to: deinstall ok config-files. The information is completely erased through dpkg-P or dpkg-- purge.

So, when the dependency is not satisfied, you can directly open this file, imitate the writing of other software, copy a paragraph and add, change the file name to the name of the missing dependency package! Dpkg will think that the package is installed on the system, thus solving the problem that cannot be installed due to dependencies.

Similarly, if the version required by the dependent package is not satisfied, you can also directly find the information of the corresponding package in the file and change the Version field to a version that meets the requirements.

Of course, these libraries are not actually installed in the system, we just fooled dpkg.

The software information in the system is generally written a lot, here is a simple example, really will not copy the system to copy this:

Package: mtestPriority: optionalSection: editorsMaintainer: Threedog Team Architecture: allVersion: 1.0.0Homepage: http://www.threedog.topDescription: test

Just replace Package with the name of the missing dependent package and add it to the status file. Remember to have blank lines with other software information.

4. Ignore the installation failure and run it directly.

The feasibility of this scheme is determined by dpkg's execution mechanism for the software installation process. The timing for dpkg to deal with dependencies is: "release the file, then detect the dependency, and then complete the final configuration."

In fact, you can write another field in the control file called pre-dependency: Pre-Depends. The detection level and timing of this field is equivalent to that of the Architecture field. If the dependency written in this field is not satisfied, the installation will be interrupted directly, the file will not be released, it will not be recorded in status, and no trace will be left in the system.

Therefore, when dpkg exposed the problem of dependency dissatisfaction, in fact, the files in the package have been released to the system, but no subsequent configuration has been done. For example: desktop icon configuration, font configuration, file association settings, startup trigger settings, and so on.

But this does not prevent you from directly finding his executable file for direct execution.

If you don't know which files he released into the system: first, you can unzip and take a look at the directory structure; second, you can use dpkg-contents xxxx.deb to see which files are contained in the package.

You can also use the dpkg-S software name to see what the installed software has installed in the system.

Then find the binary executable file, usually put one under / usr/bin/, if you are lucky, you may be able to run directly.

5. Violent decompression

The plan is a little too violent and unreasonable. Move the installation package directly to the root directory, and then extract the dpkg-X directly to the current directory. Then find the binary executable program to call as before.

Only if you know what's in the package and know what it won't affect.

Otherwise, if the extracted file destroys the important files of the system, it will be an irreversible destruction and reduction blow.

And so finished, how to uninstall is also a problem.

6. Change the dpkg source code

This is the hardest solution in technology.

The main operation methods are as follows:

Clone the dpkg source code from this address: https://git.dpkg.org/git/dpkg/dpkg.git and find the dependencies_ok function in the packages.c in the source code. No matter how much is written in it, just give it return DEP_CHECK_OK; or return 2 at the beginning; it's just an enumeration.

Then compile the project to generate your own dpkg.

I have added an extra line of output to the dpkg I compiled here, and the effect is a little bit more obvious:

This function changes the dependency detection to the Depends field.

If you are pre-dependent on the Pre-Depends field, you want to change another function called depisok.

On the dpkg project source code compilation, using the Linux C project automake that set. The old gun closed his eyes and made it up. Mengxin, who didn't get started, didn't even know how to start. For an entry-level vegetable chicken like me, I have to write down a little notebook at every step, and my friends who want to play in this way can refer to: https://blog.csdn.net/Three_dog/article/details/103418141

With this self-compiled dpkg, all software can be installed without hindrance.

However, as for whether it can be used after installation, whether there will be any problem, I am afraid it depends on nature.

After all the solutions of dpkg, let's talk about rpm.

There are two reasons why rpm is not mentioned:

"one is that I am far less familiar with it than dpkg."

"second, it is really, compared to dpkg, it is maddeningly difficult to use."

There is not much difference between rpm and dpkg in a legitimate solution. You just need to change the above comparison scheme, dpkg + apt-get, to rpm + yum. We are not going to dwell on it.

Mainly talk about illegal schemes:

The mechanism of rpm makes almost all of my illegal schemes completely unavailable!

Option one

This is the only one available: ignore dependencies, which is the only illegal solution that can be targeted on rpm, just replace-- ignore-depends with-- nodeps.

Almost nothing else:

Option 2

When rpm is packaged, the configuration information is written in a .spec file, not to mention the disgusting degree of the control file on the mark. the important thing is that it cannot be unzipped from the finished rpm installation package.

You can only use rpm-- scripts-qa xxxx.rpm to view it, and what you see is so different from how it was actually written that you can even understand what it feels like to use objdump to see executable programs.

This mechanism results in the killing of scenario 2 above (unpacking the installation package, deleting the dependent fields and repackaging).

Option 3

Rpm installed into the system of software, there is also a unified file management, but! God damn it, it's managed by a database:

This is the configure parameter when compiling rpm. These three databases are optional at compile time, and the installation version is usually Berkeley DB.

With database management, it will be saved as a binary data file! Unlike our status just now directly modify the text, and disgusting (my level is also too bad on the one hand), these three databases I have been tossing around for a long time can not find the tools to add, delete, change and check them!

In other words, the operation of the content of the database can only be done by rpm, not for users.

Therefore, the above scenario 3 (modifying the status software recorded in the system) is also killed.

Option 4

The only time to install rpm depends on checking, and that is before releasing the files.

So if there is a dependency problem, not a single drop of the files in the package will be leaked into the system, and the above scenario 4 (ignore installation failure and run directly) will be killed.

Option 5

Direct violent decompression is possible. However, as mentioned above, this is really a bad policy.

Option 6

Finally, change the source code of rpm.

At my level, to be honest, I don't have the right to comment on the source code of a mature open source project, but one indisputable fact is: I imagine the above change of dpkg to the source code of rpm. After a lot of trouble, I really couldn't find how to change it.

Therefore, plan 6 (modify the project source code) is also basically aborted.

I think this is one of the reasons why many people think that dpkg is much easier to use than rpm.

Rpm manages all the data in a database, which seems to enhance security, but for the fussy Linuxer, the dimensionality reduction blow brought about by this maneuverability is simply unbearable.

In addition, it also has very difficult command combinations; frustrating software source configuration methods; and hell's difficult packaging specifications; packaging without leaving the original files and other features that make people think it is difficult to use! Packing rules are really excruciating! I accidentally dialed the wrong number and didn't even get the original file! I didn't get any! )

The above, at my current level, can provide all the solutions for the anti-celestial software dependency of Linux. It can be seen that some of the solutions are based on a little technical background.

A lot of technical problems are like this. When you delve into a certain direction, many operations that are impossible for ordinary people can do whatever you want in your hands! (my wife Shanyi: focus a little, get to the top)

And I believe that there must be a good way to solve these problems that I did not think of. If there is a boss who can provide solutions or ideas, please give me some advice!

Finally, correct a cognitive misunderstanding of many people.

Until now, almost 80% of popular science articles have tied rpm and deb files to RedHat and Debian. So that many people subconsciously think that Debian can only use dpkg,RedHat and can only use rpm.

Actually, not at all. Their relationship is the relationship between the system and the software, only that Debian comes with dpkg and apt,RedHat comes with rpm and yum.

It is entirely possible for Ubuntu to install a rpm system through sudo apt-get install rpm and then install various rpm format installation packages through rpm.

CentOS, on the other hand, can also be installed by compiling (because there is no dpkg in the yum source, poof) a dpkg, and then install various deb format installation packages.

As long as there is no conflict between the files released by the installed software, the mode of coexistence between the two on the system can even be described as case-by-case and respectful to each other.

It's not as old as most people think:

The above is the solution to the Linux dependency problem shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.