Re: Avoiding the Linux version of "DLL Hell"...
Redefined Horizons <redefined.horizons@gmail.com> wrote:
> I want to install a Debian package named "Package A".
> Package A lists as a dependency another Debian package named "Library A".
> However, if Package A requires version 2.0 of "Library A", while another
> Debian package I have installed on my system, named "Package B" requires
> version 1.0 of Library A that I already have installed.
In an ideal world, this wouldn't happen;
- Library packages should be named not only after the library they
provide, but the ABI version of that library as well. (eg; libgnutls11,
libgnutls12, libgnutls13).
- Binaries depend on the package that contains the version of the
library they were compiled against.
- These libraries have unique sonames (the stuff that comes after
the ".so" in the filename; libgnutls.so.11, etc)
- These libraries should never conflict, *however* in most cases
their -dev packages probably should (because the -dev package provides the
root ".so" that ld/libtool looks for, as well as header files specific to
that ABI/API).
Of course, not every library comes out in such an "ideal" way, but
those that don't are a pain to properly link against anyway. :-)
> Here is my question. Can I create a custom Debian package for Library A
> that satisfies the dependency requirements of Package A, but still keep
> the older version of Library A required by my other programs?
>
> In essence, I want to create my own custom Debian Packages to avoid
> conflicts in package dependencies. Is this plausible?
Definately, although building such a package sounds a little bit
convoluted. If you actually *need* this, then it probably means that said
library was either improperly packaged or improperly developed, so maybe a
bug should be raised against the offending package(s) too. :-)
> Thanks for the advice. I look forward to being able to contribute useful
> packages to the Debian Community.
Me too!
Cheers,
Tyler
Reply to: