You are probably using a old version of Lintian, I would guess << 2.5.95.
yes, you are right, the lintian coming with Ubuntu is 2.5.81. I will find a way to upgrade.
I think that you should really repack the tarball at uscan time, see https://wiki.debian.org/BenFinney/software/repack
If you do it, then the problem that you mention will not happen.
I see (and finally understand what uscan is for). I had been running a "repacking" script of my own,
https://salsa.debian.org/fangq/libzmat/-/edit/zmat/README.md
you previously mentioned about making changes to the orig package
in the "override_dh_auto_configure" section. do you think
that could also achieve the same goal? In a way, I am looking for
the equivalence to the "%prep" section in an RPM spec file,
like I did in this Fedora package:
https://src.fedoraproject.org/rpms/octave-iso2mesh/blob/master/f/octave-iso2mesh.spec#_61
I believe the upstream tarballs do not contain any "non-DFSG-free" files, but if the "repacking" is also appropriate for the purpose of changing folder structures, dropping redundant files etc, I will be happy to redo the repo after reading about this.
If these are general tools, that can be useful outside Octave, *and* if they do not conflict with other packages, then you should put them in /usr/bin and create a iso2mesh-tools, as you suggest.
ok, I believe that is the case.
I am not sure this is a good idea. If you use the symlinks, then you will have to add a dependency octave-iso2mesh → matlab-iso2mesh or vice-versa. This means that a MATLAB user will have to have installed octave-iso2mesh, which will pull Octave and a host of dependencies. The converse is also undesirable (i.e. Octave users being forced to install matlab-support).
My suggestion would be to duplicate the files across the two packages. It is not a big deal.
sounds perfectly reasonable.
let's decide on the best way to handle the upstream tarball, and then I will make the suggested changes.
thanks
Qianqian
Best,
Rafael