Use tar-ignore to override the default values
dpkg-source by default filters a list of files, including "*.so".
We use the "*.so" files for our tests, so we want them to be included.
/cc @smcv @jpwhiting
Merge request reports
Activity
Based on this discussion https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735377#49 it seems like the problem might be the
dpkg-source -i -I
thatdeb-build-snapshot
uses?To make this work I had to change
deb-build-snapshot
arguments from-us -uc -i -I
to just-us -uc
https://salsa.debian.org/smcv/deb-build-snapshot/-/blob/f0197ae5/deb-build-snapshot#L668Even without the
-I
,dpkg
still excludes files that are listed in its default list. But fortunately in this case the optiontar-ignore
of this MR successfully overrides the default exclusion list and the*.so
files are preserved.To sum it:
-
deb-build-snapshot
master +s-r-t
master =*.so
files are excluded -
deb-build-snapshot
master +s-r-t
!114 (closed) =*.so
files are excluded -
deb-build-snapshot
without-i -I
+s-r-t
master =*.so
files are excluded -
deb-build-snapshot
without-i -I
+s-r-t
!114 (closed) =*.so
files are NOT excluded
Edited by Ludovico de Nittis-
Oh, interesting!
I think strictly speaking,
deb-build-snapshot
should just be ignoring.git
and nothing else, like dgit and vectis do.-i -I
is the big hammer for source trees you don't have good control over.We can probably work around this for now by reverting my commit that made it a native package, because
--tar-ignore
/-I
isn't used for non-native packages (we use Meson to build the orig tarball in that case).However, relying on the test data containing files named
.so
doesn't seem very robust, because lots of tools are going to assume that those are built files rather than sources. Maybe we can build the sysroot programmatically, either frommeson.build
or from the C code, rather than shipping it in the tarball?Actually, can I hand this back to you? Programmatically generating the sysroots is straightforward, but gluing it into the build system isn't, and I don't want to add too much to my stack until I've cleared some tasks. What I have so far is on !115 (merged).
Closing in favour of !115 (merged).
When !115 (merged) has been done, we can reapply de9040ba (after testing it properly, like I didn't do first time round - sorry, my fault).