* Manoj Srivastava <[EMAIL PROTECTED]> [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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
