Re: Cyclic dependencies in octave2.1 packages?
Release team,
I think Richard is basically correct in his analysis. Bjorn's page lists
octave2.1
octave-forge
octave-sp [ source package semidef-oct ]
as mutually blocking themselves on Alpha -- but buildd.debian.org shows that
all packages have built correctly.
On Thu, Dec 02, 2004 at 11:00:34PM +0100, Richard B. Kreckel wrote:
> Hi!
>
> I was worried about the status of my package libginac1.3 in
> debian/testing. It appears to be interlocked with a bundle of packages
> that are part of source package octave2.1: octave2.1, octave2.1-headers,
> octave-sp and semidef-oct. Glancing at [0], it appears to me that those
(Small correction: octave2.1-headers and octave2.1 are both generated from
the same source package, octave2.1)
> packages are stuck in a mutual cyclic dependency and they could just go
> all in together. Is that wrong? If so, what's the matter and what can we
> do about it? If it is correct, could you hint at debian-release that this
> dependency cycle ought to be overcome by installing them all together?
This would appear to be correct.
I'm not sure what is wrong with my Depends. Octave does hard code its
version in the path for dynamically loadable code. This requires packages
like octave-forge and octave-sp to be rebuilt with each Octave release. I
have finally added 'hard' Depends similar to what Python does:
octave-forge:
Depends: octave2.1 (>= 2.1.63), octave2.1 (<< 2.1.64), ${shlibs:Depends}
octave-sp:
Depends: octave2.1 (>= 2.1.63), octave2.1 (<< 2.1.64), ${shlibs:Depends}
Or is all this caused by one of the half-dozen libraries pulled in by
octave-forge?
Thanks for waving the cluebat at me.
Dirk
>
> Regards
> -richy.
>
> [0] <http://bjorn.haxx.se/debian/testing.pl?package=octave2.1>
> --
> .''`. Richard B. Kreckel
> : :' : <kreckel@debian.org>
> `. `' <kreckel@ginac.de>
> `- <http://www.ginac.de/~kreckel/>
--
--
If your hair is standing up, then you are in extreme danger.
-- http://www.usafa.af.mil/dfp/cockpit-phys/fp1ex3.htm
Reply to: