Re: Should -dev packages providing .pc files depend on pkg-config?
On Mon, 7 Apr 2008 23:21:51 +0200, Andreas Bombe <email@example.com> said:
> On Mon, Apr 07, 2008 at 01:14:50PM -0500, Manoj Srivastava wrote:
>> On Mon, 7 Apr 2008 18:20:56 +0200, Bernhard R Link
>> <firstname.lastname@example.org> said:
>> > Here I have to contradict. No -dev package should ever depend on a
>> > compiler or linker, even if that tool was not already in
>> > build-essentials.
>> Can you provide some rationale for this assertion? I can see why one
>> might not tie the development tool very strongly with a particular
>> compiler or compiler version, to allow a developer to use it with an
>> alternative development tool, but I can see why one may want to
>> depend on a generic foo-lang-compiler-or-interpreter virtual package.
>> There is obviously a trade off here -- the need to the development
>> package to be useful on installation, by ensuring that the tools
>> required to use the package are also installed, versus the need to
>> allow people to use the package with alternate developer tools. Ar
>> there other considerations and use cases you have in mind?
> I can't speak for Bernhard of course, but my opinion is that such
> dependencies of any sort are redundant. The development packages are
> not usable by themselves, they are used by programs. If it's a dev
> package for a C library that is used in a C program you want to
> compile, then it's your program depending on the C compiler already.
> If it's a module for Python used in a Python program, then the program
> depends on the Python interpreter already.
I am not sure I find this argument convincing. For
dependencies, we have ruled that if a package depends on library A, and
that library depends on library B, the package in question should
still only mention library A only -- and let libA's dependencies pull in
In this case, again, if my dev package requires a tool not in
build depends now, I should declare it, for the same reason -- the next
upload of the dev package might have different tools, or eliminate
tools -- and putting that build dependency in all the packages that
use my dev package is hard -- especially when we consider the cases
when the scenarios where these dependencies might change over time.
The truth about a man lies first and foremost in what he hides. Andre
Manoj Srivastava <email@example.com> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C