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

More structureal Octave path problem [Was: Problem with octave-plplot]

  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

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 ->
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 ->

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 


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: