From Mandriva

Dependencies on Cooker circa the release of Mandriva Linux 2005 release show that the unzip(1) file compression and archival utility depends on libusb0.1_4, a library used by USB-aware userspace applications. Does unzip really needs USB support, or is it a result of dependencies gone out of control?

Contents 1 Introduction 2 The dependencies 2.1 The layout 2.2 Analysis of the dependency graph 3 A solution 4 Conclusion

Introduction

An attempt to remove the libusb package (a library used to write USB-aware applications) from a Mandriva system results in indirect removal of the unzip, a file compression and archival utility. The relationship between an archiver and USB isn't obvious, and demands a more in-depth analysis of the dependency chain that resulted in such an unexpected scenario. We can safely rule out that unzip directly needs USB support, so what is causing this dependency?

In some cases we expect to have a small on-disk system footprint. This could be the case, for example, of a small machine without USB ports and Flash-type storage where disk estate is at a premium. It is not known if in any foreseeable future Mandriva or third parties will wish to install the system in such type of minimal platform, but having a well-organized, clean core system is important even in case of a more complete installation.

It is certain that this type of dependency chain is not the result of an ill-designed system. Instead, the entropy increase resulting from continued development is most likely the cause of the problem.

The dependencies

The layout

Fig. 1: Dependency graph of unzip and libusb

A quick inspection of the unzip and libusb0.1_4 packages allows charting the dependencies in the graph shown in Fig. 1. The relationship between unzip and libusb isn't immediately obvious in the graph, so let's track it down.

Analysis of the dependency graph

Fig. 2 highlights the dependencies that tie unzip to libusb. The requirements chain has ten hops and actually ties the entire system to libusb via glibc and rpm. Conceptually an archiver has no need for USB support, so we expect that the graph has an edge representing a dependency that shouldn't actually be there.

Fig. 2: Highlighted dependency path

Further analysis of the graph shows a number of suspicious dependencies that are candidates for removal:

1. The libc depends on the package manager. This is also part of a circular dependency. This particular requirement also ties all packages requiring glibc to rpm.
2. Modutils requires rpm. This dependency is also not obvious and is possibly an error.
3. Rpm requires unzip. It can be the case in a generic setup, but Mandriva packages are constrained by policy to use bzip2, so this requirement is also not needed.
4. Pam requires initscripts. This dependency warrants further investigation.
5. Initscripts requires udev. This is objectionable, initscripts should make use of udev if, and only if, udev is installed. This is probably caused by a monolithic rc.sysinit (Conectiva Linux had this problem and it was solved by breaking rc.sysinit down in multiple initialization scripts like Debian and SuSE).

A solution

There are different possible solutions for this problem. From the five questionable requirement dependencies shown above, three are part of the unzip to libusb chain; removal of any combination of these dependencies would break the chain and decouple the packages. However, the ideal layout could be achieved by removing all five dependencies, as depicted in Fig. 3.

Fig. 3: New dependency chart

Dependency on libc becomes a non-issue in the new scenario, and the glibc node has been removed from the chart for clarity. Edges of the former unzip to libusb requirement path are still highlighted in red, but are no longer part of a single chain.

Conclusion

USB support is not required to archive and compress files, and the unzip dependency on libusb results from at least one unnecessary requirement in the dependency chain. Five possible candidates were listed, and the ideal case of dependency decoupling happens with all five dependencies removed. Further investigation is needed to determine if any of these five dependencies are actually essential.

The decoupled system reduces the size of the core system and allows installation in systems with special needs. Additionally, elimination of dependency loops and reduced complexity of the system make maintenance and planning of upgrade strategies easier for developers and system administrators.