[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: is it a bug to not depend on a library package needed for some binary?

Martijn van Oosterhout <kleptog@gmail.com> writes:

> 2005/7/17, Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>:
>> Karl Chen <quarl@cs.berkeley.edu> writes:
>> > Suppose package P contains files /usr/bin/B1 and /usr/bin/B2.  B1
>> > is the important program, and B2 is not as important.  Is it OK
>> > for the declared package dependencies to not satisfy all the
>> > run-time shared library dependencies of B2?  What if they are
>> > listed in Suggests?
>> >
>> > I have found many such packages.
>> Any examples?
>> From my gut I would say thats a serious policy violation and if P
>> can't depend on all libs it should be split into B1 and B2 packages
>> and B1 suggest B2.
>> If your examples are like B1 is a console program and B2 an X program
>> and P doesn't want to pull in X for console users then splitting is
>> the right thing to do. isdnutils would be example of having split due
>> to this in the past.
> Let say, hypothetically, the maintainer made a script called
> /usr/bin/B2 which would check for the dependancies. If they're not
> present error out with a message "please install program Y". If they
> are present, exec the original.
> Would this still be a policy violation?

Probably not. But damn anoying. If it is a binary that just fails with
a linker error then I would definetly report a bug.

For a few K script on top of a say 1MB package splitting out that one
script wouldn't be sensible.

On the other hand if Y is a say 10K package itself depending on it as
well doesn't hurt anyone, does it?

It's all relative. If you can see a good reason to violate policy then
even that can be allowed.


Reply to: