More structureal Octave path problem [Was: Problem with octave-plplot]
John:
Please try to read through -- this is from an exchange between Rafael
in the role of the frustrated octave-plplot maintainer, Steve as the helpful
and clueful release manager, and Dirk as an almost innocent bystander who
also happens to be frustrated about a lack of octave-forge in testing. Oh,
and I will also include Richard, who is ginac maintainer (and upstream
hacker) whose ginac package is upheld by octave-forge as well.
On Mon, Jan 03, 2005 at 05:12:23PM -0800, Steve Langasek wrote:
> On Sun, Jan 02, 2005 at 01:15:10PM +0100, Rafael Laboissiere wrote:
> > * Steve Langasek <vorlon@debian.org> [2005-01-01 18:57]:
>
> > > Please open an RC bug report, tagged sarge, against one (or both) of the
> > > packages to document this issue.
>
> > Done: Bug#288186.
>
> > > Have steps been taken to ensure this kind of API-skew doesn't affect
> > > testing in the future, or do you need help from the release team to craft a
> > > solution to that problem?
>
> > I think that this is the responsibility of the maintainers of the packages
> > (Dirk and me). We are quite responsive to new upstream releases of Octave
> > and that should be enough to ensure smooth transitions from unstable to
> > testing, unless there is lost of binaries at the build daemons or compiler
> > blocking in sarge, as is currently the case.
>
> As I've explained to Dirk on IRC, the problem is that dealing with this
> issue only when the dependencies have been broken is too late. Past
> experience is a strong indicator that Depends: octave2.1 (>= 2.1.64) is too
> weak, because what octave-plplot actually depends on is "a version of
> octave2.1 that provides octave API version 11", and we've already had at
> least 4 API versions within the octave2.1 package series. Of course,
> there's currently no way for octave-plplot to express such a dependency, but
> there should be; probably with a virtual package, e.g., octave2.1 Provides:
> octave-api-11.
>
> This is important because the current situation allows users to break their
> systems with partial upgrades, and it also allows packages to become
> out-of-sync in testing. Both are undesirable, and both are fixable in the
> vast majority of cases by getting the package dependencies right. It does
> mean that more handholding is (currently) required from the release team to
> get octave package updates into testing, but this is a price we're willing to
> pay to ensure testing is as usable as possible.
>
> Dirk, you spoke on IRC of packages such as kmatplot having even tighter
> dependencies, requiring the exact minor version of octave2.1 that they built
> against. It appears kmatplot already deals with this problem, e.g.,
>
> Package: kmatplot
> Version: 0.4-7
> Recommends: octave2.1 (>= 2.1.57), octave2.1 (<< 2.1.58)
>
> If octave-plplot has the same tight dependency, and not just a dependency on
> the octave API version as suggested by the error message in Raphael's mail,
> then the same solution is also warranted.
As I tried to explain on IRC, the problem is that every /binary/ Octave
module depends on the /actual/ Octave version it is built against. See here
for the two most recent versions of octave-forge, and 2.1.64 and 2.1.63
respectively:
edd@basebud:/var/local/cache/pbuilder/result> dpkg -c octave-forge_2004.11.16-3_i386.deb | grep 2.1.64 | grep ".oct$" | tail -1
lrwxrwxrwx root/root 0 2004-12-04 11:09:54 ./usr/lib/octave/2.1.64/site/oct/i386-pc-linux-gnu/octave-forge/vpa.oct ->
symbols.oct
edd@basebud:/var/local/cache/pbuilder/result> dpkg -c octave-forge_2004.11.16-2_i386.deb | grep 2.1.63 | grep ".oct$" | tail -1
lrwxrwxrwx root/root 0 2004-11-18 22:54:09 ./usr/lib/octave/2.1.63/site/oct/i386-pc-linux-gnu/octave-forge/vpa.oct ->
symbols.oct
This is nothing that Rafael or I can do anything about as John imposes it
upstream (for reasons we always consider to be fair enough: frequent changes
in Octave). But as Steve outlines above, it has its costs, and it really is
not desirable.
I think Steve's idea of using an Octave API counter may be better.
John: Would it be possible to replace
/usr/lib/octave/$VERSION/
with
/usr/lib/octave/$APICOUNTER/
in the hope that rapid-succession uploads could have a chance of not
requiring an increment to $APICOUNTER -- yet allowing you to increase the
counter whenever "something significant enough" changes?
Best, Dirk
>
> Thanks,
> --
> Steve Langasek
> postmodern programmer
--
If you don't go with R now, you will someday.
-- David Kane on r-sig-finance, 30 Nov 2004
Reply to: