Hello Jan, This would be a great package to have it on Debian,
I usually do a quick review to see if I spot any noticeable issues before I do a deep dive on it (which I would to during this weekend), and I notice an issue on d/rules, there are some commands doing: "test -d foo || git clone bar" This is an issue because it goes against our policy of not using network during the build process[0], you can read a recent discussion about it on LWN as well[1]: "For packages in the main archive, no required targets may attempt network access, except, via the loopback interface, to services on the build host that have been started by the build." In order to fix this issue you have two options: 1) Package those projects separately and add them to B-D. 2) Repack the upstream tarball and vendor/bundle them in. You would usually prefer option 1 when the libraries could be reused by other packages and option 2 when they are likely to only be used by your package (usually means the same upstream). But sometimes, even if the library could be used by another package in the future (but it's not currently), you can go with option 1 if it makes more sense. Beware that there is not a clear consensus on this matter so some arguing might be needed (even though we have examples of packages vendoring libraries which are already available in a standalone manner on main). Looking at the three libraries we are talking about: simsong/be13_api simsong/dfxml (watchout cause it looks like this one has just been moved to a different repo) nbeebe/sceadan It looks like it's totally fine to vendor be13_api and dfxml, it seems like sceadan is generic enough to be used by other projects but I didn't do a proper check. I suggest you consider the options here and let us know what you think it's best. Oh, and since you are in contact with upstream, this sort of issue is sometimes solved by upstream providing a release tarball that includes the submodules. The issue is that as far as I know Github does not provide this feature, so they have to use a script to generate the tarball and attach it to the release. This makes the tarball easier to be worked on/packaged by other distros as well[2], but it's also easy for us to workaround so this is a tradeoff between bothering upstream vs repacking on our side. Considering upstream is focused on a rewrite of bulk_extractor, it might be a good idea to repack it ourselves, I just wanted to let you know so you're aware of the ideal fix for this if it happens again in the future. Thanks for your work! [0] https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules [1] https://lwn.net/Articles/700465/ [2] And I guess it's also easier for users who wants to build it themselves, as plain git clone will not checkout the submodules. -- Samuel Henrique <samueloph>
