Le jeudi 03 octobre 2019 à 15:24 +0200, Rafael Laboissière a écrit : > * Rafael Laboissière <rafael@debian.org> [2019-10-02 09:27]: > > * Mike Miller <mtmiller@debian.org> [2019-10-01 14:34]: > > > > > Maybe instead of a dependency on a specific liboctaveN, we could > > > have dh-octave inject dependencies on "octave (>= 5.1~), octave (<< > > > 6)"? This is essentially the stability promise we are aiming to > > > provide now upstream. > > > > Would this be enough? What will happen if, in the 5.2 release, the > > soname is bumped from liboctave7 to liboctave8? > > Another possibility is to have dh-octave injecting the specific > liboctaveN dependency, according to the version of octave used to > build the package. What do you think? I don’t think injecting an artificial liboctaveN dependency is a very good solution, because it violates the usual assumptions about dependencies on shared libraries, and it goes against upstream’s will to eliminate this dependency. Nevertheless, I think we’ll have to design something along similar lines. Either adding versioned dependencies against Octave as Mike suggested, or introducing a virtual ABI package as is for example done for R. However, may I suggest that we postpone that work for later, and that for the time being we focus on completing the Octave 5 transition? Other transitions are waiting for ours to complete, and there are about 16 packages (inside and outside the DOG) currently failing to compile against Octave 5. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part