Taking over program names in Linux is generally hard

May 30, 2018

One reaction to the situation with net-tools versus iproute2, where the Linux code for ifconfig, netstat, and so on is using old and incomplete interfaces and is basically unmaintained, is that the new and actively maintained iproute2 should provide its own reimplementations of ifconfig, netstat, and so on that preserve the interface (or as much of it as possible) while using modern mechanisms. Setting aside the question of whether the people developing iproute2 even like the ifconfig interface and are willing to spend their time writing a version of it, there are additional difficulties in doing this kind of name takeover in Linux.

The core problem is that existing Linux distributions and existing systems will already have those programs provided from a completely different package. This generally has two effects. First, some Linux distributions will disagree with what you're doing and want to keep providing those programs from the other package, which means that the upstream package has to be able to build and install things without its version of the programs it's theoretically trying to take over (ie, the new release of iproute2 has to be able to build without its version of ifconfig et al).

Second, when distributions decide that they trust and prefer your versions of the programs better than the old ones, they have to be able to do some sort of package upgrade or migration that replaces the other package with a version of your package that has your version of the programs included. There are also inevitably going to be distributions that will want to give users a choice of which version of the programs to install, which means that some of the time the distribution will actually build two binary packages for your package, one with your core tools ('iproute2') and one with your replacements for the other package's programs (a hypothetical 'iproute2-nettools', that has to cleanly replace 'net-tools').

Some of this work has to be done by the developers of the new package; they have to make replacement programs that are compatible enough that users won't complain, and then they have to make it possible to not build these programs or build them but not install them. Other portions of the work have to be done by distributions, who have to package all of this up, make sure that they don't accidentally create package conflicts, make sure package upgrades will work well and won't blow up dependencies, and so on. Since this complicates the lives of distributions and the people preparing packages, it's not something that they're likely to undertake casually. In fact, distributions are probably not likely to undertake it at all unless the developers of the new package actively try to push for it, or unless (and until) the programs in the old package become clearly broken and basically force themselves to be replaced.

(I'm generously assuming here that the old package is truly abandoned and everyone agrees that it has to go sometime. If there are people who want it to stay, you have additional problems.)

All of this is the consequence of there being multiple Linux distributions that will make different decisions and that Linux distributions are developed independently from each other and from the upstream packages. If everything was handled by a single group of developers, such takeovers would have much less to worry about and to coordinate (and you wouldn't have packaging work being done over and over again in different packaging systems).

Written on 30 May 2018.
« An incomplete list of reasons why I force-quit iOS apps
Extended Validation TLS certificates are basically invisible »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed May 30 01:44:39 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.