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

Re: Should -dev packages providing .pc files depend on pkg-config?



* Manoj Srivastava <srivasta@debian.org> [080407 20:19]:
> > 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?

- There are multiple compilers. Even within gcc there are multiple
  versions which look as different compilers from a package standpoint.
  No alternative list in a dependency can ever be complete. Every new
  compiler may work for some -devs and for some not, so even virtual
  packages will often tend to pull the wrong thing in.

- No compiler is an essential package[5]. So forcing people to install
  them or equivs generated pseudo packages just to use their self-
  compiled unpackages compiler would show there is something very wrong.
  (Building your own compilers may not be a general use case. But when
  a -dev package has so special needs that the point before this does
  not sounds confincing, I'd assume it has so special compiler
  requirements that people building unpackaged versions would actually
  be quite common).

- Classic asymmetry of dependencies. When you look at dependencies as
  "foo is only useful with bar", we are currently missing many
  dependencies and would have to add so many that we hardly get a useful
  system. Having a compiler is not enough for a -dev package to be
  useful. You also need a source to compile. (which cannot be even
  expressed as dependency). And a library itself is totally useless
  without any binary linking against it[1]. But no library depends on
  some virtual user-of-lib package, <litte-bit-of-sarcasm> though
  it would make deinstalling no longer used packages so much easier.
  </little-bit-of-sarcasm>.
  Additionally to many unexpressable things, this would create a
  large amount of cyclic dependencies, which our tools cannot properly
  handle[2].
  So the point of an dependency is "foo only works with bar installed"
  (or the functionality definition from policy):
  A library works (as library) when things can link against it, i.e.
  when all it NEEDED sections are fullfilled. An application works
  (as application) when it can be run according to it's supposed purpose
  (i.e. only missing input data that is supposed to be written to use
  it). An -data package works when all the data in it is useable
  (i.e. does not include or reference[3] other data not in the package
  itself and not in a package it depends), but does not depend on a
  package doing anything with this data.
  And a -dev package in my eyes works when a preprocessor can include
  the header files (i.e. #included header files are there for a
  significant amount of functionality) and/or a suitable linker can create
  executables from it (i.e. there are .so or .a files working in enough
  cases to be significant).
  The compiler and linker are here things that use it the content of
  the package. As are a program using the library users of a library and
  not a dependency. (or as a shell is a user of an application and not
  the dependeny of a program[4])

>         I see recommends as a middle ground between a depends and a
>  suggestions; can you articulate why this middle ground is unaceptable,
>  as you assert above?

My point is that a recommends is no middle ground. A recommends is just
a dependency that is not absolute. Thus limiting the negative effects
from extremly annoying to annoying.
A Suggests is a possible compromise, and I did not deem it unacceptable.

Hochachtungsvoll,
	Bernhard R. Link

[1] or being able to dlopen it, for you nitpickers
[2] well, dpkg is relatively good at it, but apt sucks.
[3] though few data formats support this.
[4] yes, I know, here people could start with "but bash is essential"
    just like in the post where I jumped into the thread last.
[5] not yet, perhaps future perl will change that, but that does not
    matter.


Reply to: