Web lists-archives.com

Re: Depends/Recommends from libraries




Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx> writes:

> I think the right way to solve this problem is to declare that:

>  * When a library package is installed, the Depends and Recommends
>    of the library should be appropriate on the assumption that:

>      - the library package is only installed because it is the dormant
>        runtime-link-dependency of an executable or other library;

>      - none of the functions in the library are going to be
>        called.

>    Normally this will mean that the library will reference only other
>    library packages, on which it has runtime-link dependencies.

>  * If a library needs or wants additional software installed,
>    if and when functions in that library are called, this
>    should be documented in the /usr/share/doc/BAR/README.Debian.gz for
>    the corresponding -dev library package.  (If churn is
>    likely, a library-specific virtual package name may need
>    to be documented, and provided as appropriate.)

>  * Programs which call functions in libraries (directly or indirectly)
>    should arrange to Depend on, Recommend, or Suggest, the appropriate
>    infrastructure, as documented by the -dev package(s).

I think this would be a great way of introducing spurious bugs in our
distribution from people who don't happen to read the README file and miss
dependencies they actually need because they're used to Debian properly
picking up shared library dependencies and to the dependencies of any
given package being fully self-contained.  Both of which, I should add,
are major *features* of our distribution that many of us have worked very
hard to achieve.  I'm opposed.

Now, if this were taken a further step so that dpkg-shlibdeps would
provide some mechanism to *automatically* add those downstream
dependencies to packages that depend on the library unless the
dependencies were explicitly suppressed, I wouldn't be as strongly
opposed.  It still feels like needless complexity to me, but at least we
would default to the known-working dependencies but provide an easy way
for a library consumer to relax those dependencies as needed.  But that
would require writing some additional infrastructure and relabeling all of
those libraries to have a new dependency field, and I strongly suspect
it's more effort than it's worth.

-- 
Russ Allbery (rra@xxxxxxxxxx)               <http://www.eyrie.org/~eagle/>