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. Thanks, -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature