Re: Packaging crowdsec and some other packages
On Mon, Dec 21, 2020 at 6:21 PM Cyril Brulebois <cyril@debamax.com> wrote:
>
> Hi,
>
> El boulangero <elboulangero@gmail.com> (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
Reply to: