Hi Rafael, Le samedi 06 janvier 2024 à 18:08 +0100, Rafael Laboissière a écrit : > In the process of upgrading the Debian package octave-control, from > upstream version 3.6.1 to 4.0.0, I noticed that the tarball contains the > source files for the SLICOT library v5.8 [*]. > > Since the release of version 2.3.53-1 of the octave-control package, we > have been build-depending on libslicot-dev and linking the > __control_slicot_functions__.oct file against libslicot0.so, instead of > building a local, static library for SLICOT. > > Now, the version for the Debian packages for libslicot* is > 5.0+20101122-4. Even if the package is upgraded to the latest upstream > version (5.8), and we continue to dynamically link octave-control against > it, there will remain a problem with debian/copyright, which does not > mention the BSD-3 license of the SLICOT files, shipped with the upstream > tarball. We should either remove the SLICOT files and repackage the > upstream tarball or add a stanza for src/slicot/* in debian/copyright. > The latter solution would be a little bit awkward, since we would not use > the SLICOT sources included in the upstream tarball. > > What do you think? I am the maintainer of the Debian package for SLICOT. The package is currently at upstream version 5.0+20101122 because it used to be the last version published under a free software license, namely the GPL v2 (later SLICOT versions were proprietary, and were therefore not suitable for Debian). The fact that there is a version 5.8 of SLICOT under the BSD 3-clause license is news for me. I admit I am quite surprised by that, because I previously had conversations with SLICOT upstream which indicated that they were not willing to go back to a free software license; but if this information is confirmed, this is great news. I would like to first clarify and understand that unexpected move around SLICOT (moving from GPL v2 then proprietary then BSD 3-clause). Then I will update the Debian package if it is indeed possible. I suggest to wait until the situation around SLICOT is clarified before uploading the new octave-control. Regarding your question, my understanding is that the Debian best practice is to keep tarballs unmodified whenever possible, which means keeping the embedded SLICOT in the source tarball, even if we don’t use it. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part