[nSLUG] Why you are not seeing software ported to Linux

Daniel Morrison draker at gmail.com
Wed Jun 22 22:31:20 ADT 2011


Thank you for explaining this to me. It does certainly make sense...
from a certain perspective :)

On 22 June 2011 21:08, Ben Armstrong <synrg at sanctuary.nslug.ns.ca> wrote:
> On 22/06/11 06:44 PM, Daniel Morrison wrote:
>> strange habit of splitting up packages into 'binaries' and 'development'.

> 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.

Interesting. I would not have said that (it dominates). In fact I have
never done it, nor have I done the equivalent (even more complicated)
on RHEL, not in 15 years of administration. Typically, either the
software I need is pre-compiled in a repository, or I need to compile
it from source manually. Compiling from source goes like this:

less README.txt
less INSTALL.txt
ls -l /usr/lib/libjpeg.so*
# OK, good, I have the required dependency
./configure ....
ERROR: cannot link with libjpeg
# %#$@!

> 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.

It would be nice if the -devel packages were included in the default
install, or that (current) binary library package caused the matching
-devel package to be installed as well. In fact, this is (more or
less) what happens with Slackware. The last package you install is the
one whose header files are available for compiling against. To switch
to the older headers, reinstall the older package.

> So there is a logic to it that is there to help users, not hinder them.

Thank you. Even though I don't (at present) agree with the practice,
understanding the rationale goes a long way to making me accept it! I
can also now offer a real explanation to my users (who are constantly
asking me why they can't compile their code, when they can see the
"missing" library right there in /usr/lib!)

-D.



More information about the nSLUG mailing list