Sign me up Login

Details about package smooth

Name: smooth
Uploader: Xiyue Deng <manphiz@gmail.com> (Debian QA page)
Description: libsmooth-dev - Smooth Class Library (development files)
libsmooth-0.9-0 - Smooth Class Library (runtime libraries)
libsmooth-bin - Smooth Class Library (binary files)

Package uploads

Upload #1

Information

Version: 0.9.10-1
Uploaded: 2026-02-17 07:28
Source package: smooth_0.9.10-1.dsc
Distribution: unstable
Section: libs
Priority:
Homepage: https://www.smooth-project.org/
Vcs-Browser: https://salsa.debian.org/debian/smooth
Vcs-Git: https://salsa.debian.org/debian/smooth.git
Closes bugs: #1127483

Changelog

 smooth (0.9.10-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1127483)

QA information

Comments

  1. debian/copyright:
    +Files-Excluded: libraries/v8/*
    Needs work Ermakov Alexander at Feb. 25, 2026, 2:45 a.m.
  2. Hi Ermakov, thanks for your comment!
    
    Regarding V8, the library is licensed under BSD-3-Clause which is compatible with DFSG.  Also, the V8 support is not built by default (see [1]), so there is no risk of vendoring. So I don't think we need to exclude them from the source. I hope this resolves your concerns.
    
    [1] https://salsa.debian.org/debian/smooth/-/blob/debian/latest/Makefile-options?ref_type=heads#L80-81
    Xiyue Deng at Feb. 25, 2026, 3:08 a.m.
  3. The package is built without v8. Extra code is not needed, especially since it may cause copyright issues.
    Needs work Ermakov Alexander at Feb. 25, 2026, 3:22 a.m.
  4. I want to understand more about this.
    
    Currently I don't see any potential copyright issue as v8 is licensed under BSD-3-Clause which is DFSG compatible.  I checked nodejs package, which contains the v8 code in libnode-dev.  The parts that remove v8 code is because they are not useful[1][2], and they didn't mention any license issues.
    
    The reason I want to make sure is that "smooth" vendored many 3rd party libraries which can be turned off so that it links against the libraries shipped in Debian.  Having to remove them is extra packaging work, and results in an incompatible tarball which is in turn incompatible with tag2upload which I have been using. So I want to make sure this is really necessary before doing this.
    
    [1] https://salsa.debian.org/js-team/nodejs/-/blob/debian/latest/debian/copyright?ref_type=heads#L42-43
    [2] https://salsa.debian.org/js-team/nodejs/-/blob/debian/latest/debian/copyright?ref_type=heads#L61-64
    Xiyue Deng at Feb. 25, 2026, 8:24 a.m.
  5. "Extra packaging work" in one command:
    
     uscan -dd --repack
    Ermakov Alexander at Feb. 25, 2026, 8:28 a.m.
  6. I know that uscan can process "Files-Excluded". Still, I want to try to see whether this is really necessary.  My main points are:
    
    * The vendored libraries are in DFSG-compatible licenses so copyright conflicts.
    
    * Repacking is more work than no-repacking: with repacking, when there is a new upstream version, I need to worry about whether there are more files to drop, and may need to update d/copyright, d/rules, etc.  Without repacking there is usually less work.
    
      - In the case of smooth, we may want to drop many more 3rd party libraries if we were to drop v8.  But given that they are all using DFSG-compatible licenses, I don't really see the necessity.
    
    * I have been using the upstream branch as the DEP-14 "upstream/latest" branch as much as possible. This way Salsa will also have an exact copy of the upstream branch. WIth repacking, I need to use pristine-tar to track the repacked tarball and I cannot synchronize the upstream branch.
    
    Thanks again for your review, and I hope the above can explain why I'm kind of insistent on preferring not to repack when really necessary.
    Xiyue Deng at Feb. 25, 2026, 10:15 a.m.