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.
MfG
Goswin
Reply to: