[nSLUG] Why you are not seeing software ported to Linux
George N. White III
gnwiii at gmail.com
Thu Jun 23 08:45:56 ADT 2011
On Wed, Jun 22, 2011 at 9:08 PM, Ben Armstrong
<synrg at sanctuary.nslug.ns.ca> wrote:
> On 22/06/11 06:44 PM, Daniel Morrison wrote:
>> Sometimes it seems to me like many Linux distros are _purposefully_
>> making things hard for people. Both Redhat/CentOS and Ubuntu have this
>> strange habit of splitting up packages into 'binaries' and
>> 'development'. I can't count the number of times I've failed to
>> install something because, although the binaries/libraries are
>> present, the development headers are missing. With Slackware you don't
>> have this problem. The default recommended install is to install
>> everything in the official distro, and then you're not missing
> It's only strange from a certain perspective, (and one that I believe is
> no longer in the majority).
In practice, however, many scientists need to build programs that are
not packaged from sources (often a program their lab has been
developing for years). It is often difficult to determine whether a
problem is due to a missing "system" header or a configuration
issue, and also difficult to figure out which -dev packages are needed.
> If I need to build a Debian package from source, I simply 'apt-get
> build-dep packagename' and all of the -dev packages needed to build the
> package are installed for me. It's all geared towards the requirements
> of autobuilding binary packages for a binary package-based distribution,
> which is what dominates in the world of Linux distributions.
Somewhat off topic:
The debian built system can also produce packages for intel architectures
that include binaries for other archs -- needed, e.g., for qemu-ppc,
etc. Ubuntu is missing these packages and can't generate them
because their build system is intel only.
> Unlike the .so files themselves, which can exist in multiple versions on
> the same system in the same directory, differing by soname to keep them
> distinct, header files from different versions of a library installed to
> a standard location such as /usr/include will usually conflict. The -dev
> package separation means that I can keep the older libraries installed
> on my system for the sake of packages not yet working with the current
> version of the library, alongside both the current version of the
> library and its -dev package. They will all coexist peacefully. Should I
> at some point require a build against an older version of the library, I
> can switch back to the older -dev package to do that.
> So there is a logic to it that is there to help users, not hinder them.
Correct, but the problem of figuring out which -dev packages you need
Now we get helpful hints suggesting "apt-get install ..." when you try to run
a program that hasn't been installed. The next step is a tool to help figure
out which -dev packages you need. Just an aptitude option that lists
the -dev packages for the currently installed libraries would be very
I suppose there could be a tool that scans a collection of source files and
lists the associated libraries and -dev files with status (installed, available
but not installed, or unavailable).
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
More information about the nSLUG