I usually don’t want to be the one sending out stop energy but TFA is so ridiculously crack-inspired one has to wonder if those involved are on the same planet as we are.
This seriously reminds of Douglas Adams and The Hitchhikers Guide to the Galaxy: a planet(a giant computer ran by rats) was built to find the answer to Life, The Universe, and Everything. After eons of calculations an answer was found, but none could remember what the problem was, so another planet was built to find the question that matched the solution found by the other planet. Unfortunately immediately prior to the successful completion of this project that planet was destroyed to make way for a hyperspace bypass.
Just a couple of notes in passing:
1) Differences in package management, repo structures and the tools involved in installing and removing software are the primary differentiators of Linux distributions. If this “problem” was solved, there would be remarkably little left to differentiate the distributions. And the only people interested in having such a “solution” are the one’s who already think that the LSB has already provided the answer to Life, The Universe and Everything.
2) On a superficial level there are ample opportunities for distros to reach practical consensi(pl?). XDG has been achieving this and making some nice progress for some time. These solutions do not try force distros to neuter themselves but rather to work together where there is practical benefit for all involved.
3) There will never be a single unitary package management system for Linux. Each of the various package management systems have advantages and disadvantages, each have their own problems, and each enable certain things which other systems do not. This is not merely chaos or mayhem- there is method to this madness: The organizational, social, and economic structures of the various distributions are mirrored in the particular package management systems of these distributions-in a sense, and very important sense really, these factors pre-condition each other. In other words the package management system *is* the distribution, ontologically speaking. The reasons for these differences reach into the raison d’etre of the distributions themselves-which ultimately devolves into questions of the viability of the distribution itself -whether socially, or economically.
4) Never use force to achieve what people are inclined to do anyway. With each version change in the fundamental libraries which make up the Linux ecosystem new functionality is exposed and form the basis for advances in the system itself. The individual distributions strive to take advantage of this infrastructure and utilize it for their own profit. This means that despite the rather large differences in the package management systems of the various distros that there is rather high degree of homogeneity in the version numbers of the fundamental core libraries which constitute Linux across the vast majority of distros. The differences in which actual versions are used are primarily a function of time-if the window of comparison is based on a one year time frame this homogeneity is *almost* universal, whereas if one takes 6 months as the basis there is a minor degree of diversity. Massive breaks in ABI are seldom and are surrounded by years where this is not an issue-far less often that Microsoft brings out new versions of it’s own OS.
5) the moment that any third party software mandates that my system conforms in some non-superficial way to some standard of which the distribution I am using is not part of is the moment that that software dictates which distribution I must use in order to have the priveledge of using that software. This is already the case for software like Oracle-I must use specific distributions which are endorsed by Oracle if I want to use Oracle software. Changing the distro I use for something which costs me many thousands of dollars is probably not unrealistic-but for me and the vast majority of Linux users there is no demand for extremely pricey proprietary software which would justify such. Back here, in reality, third party proprietary apps have to play ball according to our game. This does not mean that a lot cannot be done to make it easier for third party proprietary apps to integrate well within Linux-and I am all for such steps, but the LBA does not represent Linux-it represents Redhat and SUSE and to a lesser extent Debian and that’s it.
If you, as a third party propietary app developer, want to get wide scale adoption of your software in Linux then hire people who will get your software into the repos of the major distributions and provide tar balls for rest of us. Make use of the XDG tools available, target a rather actual core of main libraries (ie. not gcc-2.95) and target the infrastructure behind KDE or GNOME. If your software is enterprisy target Redhat, and SUSE(SLED) and perhaps Mandriva if you are feeling liberal-forget about the rest. If your software is for mere mortal beings target fedora, opensuse and debian/ubuntu. If you make software FOSS the community will do the work for you if your software is good enough to convince the community to support it.
If i have failed to address what the the author is looking to solve, please help me to see the problem, because I cannot find the problem which is being addressed by this solution.