Hello Cyril,
just answering a few points quickly.
> [...] “Plugins” can wait a little.
If I understand correctly, you want to focus on crowdsec the program first. In this case, starting with 'dh-make-golang make -type program' is the right way to go. The source package will be named 'crowdsec', and produce a binary package named 'crowdsec'. Later on when you want to provide a library package, you will just add a new binary package to debian/control, named 'golang-github-crowdsecurity-crowdsec-dev', then add the file `debian/golang-github-crowdsecurity-crowdsec-dev.install`, and that's pretty much done already.
Many packages do that, for example nomad, consul, containerd.
> [...]
I also think you're right here. All the build depends, ie. packages you don't necessarily care about, and that might also be used by other programs, are better maintained within the team. So that there's no friction to work on it, and everyone from the team can fix or update them when needed. All these small packages are "common ground" more or less.
As for the main package crowdsec, that you care about, I guess it also makes sense to put yourself as the maintainer, or to create a "Corwdsec Packaging Team" as you suggest. Right now I maintain the
docker.io package, it's the same situation, it lives in the "Docker Packaging Team".
>
Does everything make sense so far?
Yep.
> One which seemed easy enough was the following, and the rev-deps:
> - golang-github-oschwald-maxminddb-golang
> - golang-github-oschwald-geoip2-golang
> - syncthing
So basically, when you update libraries, you should check that the rev build deps don't break. We have a tool for that, it's ratt (rebuild all the things). It automates rebuilding all the reverse build deps with sbuild, while injecting in the build environment the new package.
If ratt succeeds, then you can upload. If you're still unsure, better ask on the Debian Go mailing list before uploading, it won't hurt. Some packages are sensitive, or have many many reverse build deps. Better ask before upload until you're sure :)
If ratt fails (ie. some packages fail to build with the new library that you just packaged), then you should investigate why, and fix the reverse build-deps for the new package that you intend to upload.
If ratt fails and you don't care, and upload your package all the same, well, nothing will stop you, but it's not nice at all. You're putting more work on other people's shoulders. And it can be a lot of work. Please don't do that :)
> Speaking of rev-deps, do we have any specific tooling to inspect all the
> reverse dependencies of a given package, to make sure I wouldn't miss
> anything?
As mentioned above, check ratt, which relies on dose-ceve to find the rev build-deps, if I'm not mistaken.
Apart from that, a few comments from my experience.
Sometimes, a little patching is much better than a lot of blind packaging. For example, if you can patch a feature away, and save yourself packaging and maintaining a tree of 10+ dependencies, then maybe you should do that. You can see that at work in docker-registry, where support for relic and azure was removed. Nobody complained.
You should exclude the 'vendor' directory if there's one. It's done in the Files-Excluded field of debian/copyright. However, for the "big packages", it's fairly common to keep a few of the vendored libraries, either because it saves us from a complicated build failure, or because some dependencies are not packaged. You can see that at work in the debian/copyright file of "big packages", once again: nomad, consul, containerd.
docker.io, ... However, 1) the Files-Excluded list is a bit of a pain to maintain, 2) You're out of luck with crowdsec, they don't have a vendor directory.
Other than that, good luck with crowdsec, and welcome to the Go Team, we have many packages and need more hands!
Cheers,
Arnaud
--