“The Linux Foundation has just released a beta of a new program, Linux Application Checker (AppChecker), that’s going to make independent software vendors and other programmers start to love developing for Linux.” This program checks your application against different versions of the Linux Standard Base (LSB), and against all the Linux distributions in the LSB Database. After the test is done it will present a report about the compatibility status of your application with the various distributions, and which external libraries and interfaces your application uses.
It sounds great in theory…
Was it THAT difficult to think at something like that?
Dear Lord, the Columbus Egg.
Let’s hope this doesn’t just effect professional developers, but hobbyists too. All too often, I find myself trying to compile source code knowing nothing about the dependencies.
Or worse, you download the source, and the original programmer assumed that certain things are installed – and thus, never mention them as dependencies. I remember when I was compiling things on Solaris there would be atleast 5 different dependencies the maintainers would never mention in their website.
One would assume that these people, with atleast a minimal university programming skill set would remember the cardinal rule of ‘never make assumptions about the end users computer configuration”.
Or even worse, some projects not even not mention the dependencies in the documentation, they don’t even check them in the configure script, so the compilation will fail with some missing headers.
Unfortunately, sometimes the odd dependency gets in there without you realising you’re depending on it.
Even more confusing can be libraries that that can have different features/sub-dependencies depending on what options it was compiled with. Some libraries I have used even install different headers depending what how you compiled them.
Every piece of software has a certain set of assumptions about the end-users computer (e.g. sh is installed is a fair assumption), but sometimes one mistakenly makes the wrong assumption: “I thought that was present on every system” type assumptions. Often it’s best to create a chroot build environment only containing your expected dependencies built with the most minimal features, just to test it.
Of course, the every once in a while I think developers expect you to read the source code yourself and work out the dependencies
I had this problem when trying to install a plugin for R from R-cran recently. Most of the dependancies were easy to find but one Fortran one was totally obscure. It turned out (after a having to do a web search) that it was for was for libblas. Their seems to be a lot of confusion about the naming of the required BLAS libraries on Linux (maybe on other Unix like systems too).
My wishes, ride on the wind, ring the bell of the daybreak, Just like a bird, My wishes over their airspace…
so, good luck with that. I hope that it becomes something. Most stuff LFL does hardly get any attention.
The LSB still has convoluted view on things.
1. They want you to use a different loader? One which isn’t present on most distroes by default (e.g: requires the lsb package) AND is achievable only by using their version of the compiler? What about other compiled languages then, like D or Pascal?
2. They don’t support static/smart linked binaries. Those are the best way to get proper compatibility across distributions and they completely ignore them.
The only good thing on this app checker is that it tells you which libs you use are present in which of the major distributions.
…I was hoping this had something to do with ReiserFS.
Yeah, it will definitely kill some competition… err linux distributions.