Re: Indirect dependencies
I think part of the `confusion' in this discussion (note, that the
discussion is not new!) is that the term `dependency' is ambiguous, since
we use it for two different meanings: One refers to `requirements' of the
programs included in the package (let me call this `physical' or `real'
dependency), and the other refers to `dpkg keywords' which declare the
relationship of packages (let me call this `logical' dependency).
For example, the `lintian' program depends on the perl, file, etc.
commands. This is a physical dependency. No matter if the lintian package
specifies a dependency on the corresponding packages or not, the lintian
utility wouldn't be able to run without a /usr/bin/perl or /usr/bin/file.
Currently, the lintian package `logically' depends on the file and
binutils packages. Though, lintian also requires perl, there is no need to
declare a dependency because the perl-base package is Essential.
We should keep these different meanings of `dependency' in mind, when
talking about these things.
Now for `indirect' dependencies. A program `indirectly-physically' depends
on another program/package, iff it does not directly require that other
part, but it requires a third program/package which itself depends on that
other program/package (either directly or indirectly). (Did I lose someone
here? ;-)
The `indirect-logical' dependency is defined the same way.
Of course, we can't discuss whether `indirect-phyiscal' dependencies are
`useful', `good', or `appreciated', since we usually take upstream sources
as-is and package them up. So this discussion can only be about the
question, `in which situation are direct-logical dependencies necessary,
and in which situation is a indirect-logical dependency just as
good/preferred?'
Personally, I think the following would be `logical' :)
We use direct-logical dependencies for direct-physical dependencies and
we use indirect-logical dependencies for indirect-physical dependencies.
(As by current policy, see policy manual s2.3.4, logical dependencies on
Essential packages may be omitted.)
Such a policy has the advantage, that all physical dependencies (which
might not be obvious in all cases, like `tetex-bin' depending on `ed' ;-)
are _documented_, and thus easy to recognize and fix whenever some changes
are made to our packages. (For example, a package maintainer could easily
drop logical dependencies if these aren't necessary anymore, without
having to fear that this change breaks other packages who's maintainers
relied on a `indirect logical dependency' via the first package.)
In case I've lost some people with this `theoretically' stuff, here are
the consequences such a policy would mean for the examples, Santiago
posted before in this thread: (These are just examples for
dependencies--I'm sure the current dependencies of these packages are
already correct.)
Example #1:
pkg-order depends on perl.
perl pre-depends on perl-base.
perl-base pre-depends on libc6.
==> pkg-order physically only depends on perl. With that, it has to be
determined whether perl-base suffices, or whether "perl" is needed. In
the first case, the package wouldn't need any logical dependencies
(since perl-base is Essential), in the second it would specify
"Depends: perl".
Perl currently requires libc6, but this doesn't matter to pkg-order.
E.g., pkg-order would run fine (I think) on a "bo" system who's perl
would require libc5.
Example #2:
lintian depends on file.
file depends on libc6.
==> Lintian physically depends on:
perl (perl-base is sufficient)
file
objdump
...
Therefore, it depends on file and binutils, but doesn't depend on
libc6 (though, perl-base might have to depend on libc6).
Hope that all this doesn't make the discussion more confusing... 8-)
Cheers,
Chris
-- Christian Schwarz
Do you know schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Debian GNU/Linux? schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
http://www.debian.org http://fatman.mathematik.tu-muenchen.de/~schwarz/
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: