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

Re: dependencies and cascade



On Mon, Oct 14, 2002 at 10:01:18AM +0200, Georges Mariano wrote:
> Hello,
> 
> While exploring (juste a little) dependencies of ocaml and related
> stuff...
> 
> [3.04 ;-)]
> apt-cache show ocaml | grep Depends
> libc6 (>= 2.2.4-4), libncurses5-dev, ocaml-base (= 3.04-12)
> 
> apt-cache show ocaml-base | grep Depends
> Depends: libc6 (>= 2.2.4-4), libncurses5 (>= 5.2.20020112a-1), tcl8.3
> (>= 8.3.0), tk8.3 (>= 8.3.0), xlibs (>> 4.1.0)
> 
> apt-cache show tk8.3 | grep Depends
> libc6 (>= 2.1.2), tcl8.3 (>= 8.3.0), xlib6g (>= 3.3.6-4)
> 
> [and it works perfectly, AFAIK ;-)]

Sure, it would be a bug if it would not work.

> My question is : is there any way to avoid duplicating dependencies
> already stated by packages already installed.
> 
> e.g in the example above, few dependencies are already stated (and
> fullfilled) by tk8.3 (which is a dependence for ocaml-base), thus
> dependencies overs libc6/xlibs/... are "over-stated".

Well, what problem do you have with duplicated dependencies ?

Nothing can be gained in removing them, and anyway, they are
automatically provided by dh_genshlibs (or whatever it is called).

BTW, i guess the dependency of ocaml comes from the labltk executable,
and/or the native code labltk libraries (which know nothing about
ocaml-base).

> I know that this is probably not a trivial question, but I think that
> it is not forbidden to perform post-processing on the control file
> while building the package, isn'it ?

The problem is that you may very well break things, don't you think so ?

> Is it possible ?
> (i.e removing the dependencies which are already stated in the set of
> installed (and required) packages e.g. ocaml-base depends "only" on : 
> libncurses5 (>= 5.2.20020112a-1), tcl8.3 (>= 8.3.0), tk8.3 (>= 8.3.0)

Suppose we later one split ocaml into bytecode suite and native code
suite. Then i guess ocaml-bytecode will not have the tcl/tk
dependencies, but ocaml-nativecode will.

The real problem is, like ever, is the changes you propose worthwill, or
is it just a 'caprice'.

Friendly,

Sven Luther



Reply to: