On Mon, Dec 21, 2020 at 6:21 PM Cyril Brulebois <[email protected]> wrote: > > Hi, > > El boulangero <[email protected]> (2020-12-16): > > just answering a few points quickly. > > Thanks! :) > > (Dropping Alexandre Viau and Shengjing Zhu for the general approach to > other packages.) > > > 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. > > Alright, I wasn't too worried about how to add a binary after the fact > (those aren't my first Debian packages), I was just wondering whether > having opted for a program-only approach at first could lead to some > kind of difficulties on the long run. > > It seems that shouldn't be the case. :) > > > 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. > > Yes, that looks like an ideal situation, was just meaning to check we > shared this view. > > > 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". > > Alright. I'm not sure whether we want to be having a specific team for > it, or if it would make most sense to have the repository on Salsa > alongside all other golang-* packages (with the Maintainer not being set > to “Debian Go Packaging Team”). It might be easier to have all packaging > related repositories in the same place, instead of having to switch to a > different team, or some branch of the upstream (GitHub-based) > repository. We'll brainstorm a little more about this. > > > > Does everything make sense so far? > > > > Yep. > > Thanks for the review and comments so far, much appreciated! > > > > 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. > > Oh, great, I was hoping such a thing would exist! May I suggest adding > it somewhere on <https://go-team.pages.debian.net/>? I think I would > have expected to see it mentioned on the packaging.html page, or maybe > on some other “best practices/updating packages” page. Now that I know > it exists and how it's named, I see it's referenced on the ci.html page, > but I hadn't thought about checking that kind of page before, since it > looked like a different topic. >
Hi, the webpage repo is at https://salsa.debian.org/go-team/go-team.pages.debian.net However it was not updated frequently... And you are welcome to join the team on salsa. -- Shengjing Zhu
