Taking over program names in Linux is generally hard
One reaction to the situation with net-tools versus iproute2, where the Linux code for
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
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
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).
Comments on this page:Written on 30 May 2018.