On 2021-04-28 17:18:39, Dmitry Smirnov wrote: > On Wednesday, 28 April 2021 5:35:34 AM AEST Antoine Beaupré wrote: >> I was sorry to find out that gitlab-ci-runner didn't make it to bullseye > > No worries. Gitlab-runner, as a statically linked executable, is easy > to install from "unstable". They also release often so we would not > have obsolete release in "stable".
Yeah, that's what I did from buster, but I'm a little hesitant in sourcing packages directly from unstable, because then there's no "event horizon" when which the package becomes ... well, stable. [...] >> I am not exactly familiar with the workings of the package, > > I like simple workflow resembling the following: > > https://salsa.debian.org/onlyjob/notes/-/wikis/bp It would be helpful to have a link to those notes (or a TL;DR:) in a README.source in the source package... >> so I did this so far: >> >> git checkout upstream >> git checkout pristine-tar >> git checkout master >> gbp import-orig --uscan > > I wouldn't bother with any of that because you will have to do it multiple > times while progressively removing components from "vendor" while > accumulating garbage in the git repository. Well that's what git reset is for. :) > I had more to say about that workflow in general - you can find my > notes here: > > https://salsa.debian.org/onlyjob/notes/-/wikis/no-gbp Hum. That's a rather long read and I'm not sure I want to get into a "how my way of building Debian packages is better than yours". It seems we all have our ways and while that's unfortunate, I guess that's life. The key point, in my mind, is that each package should explicitly document its own workflow clearly somewhere, and that wasn't done in this specific package. I looked at the existing branches from Salsa and they *did* have the upstream/pristine-tar/master so I assumed gbp was the right way to go forward. I'm happy to use another workflow. >> That generated a supposedly stripped tarball, yet I got curious and >> figured I would take a look at what was in there, particularly at the >> juicy vendor/ directory: >> ... >> Holy crapamoly! Then I compared that with the previous tarball: >> ... >> Ah. So we already have 1000+ files in vendor/, and the 13.11 update >> somewhat doubles that. > > You are starting to feel the pain... :) They do that with almost every > major release. I even raised the bug with upstream once: > > https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3178 That's kind of trying to put the toothpaste back in the tube... gitlab-runner is a golang project, that is going to just keep happening, IMHO. :) >> How do we decide what's okay and what's not in here? It's kind of a >> laborious process to go through the diff... > > Typically I remove vendored components one by one, listing them in > copyright/Files-Excluded (and replacing with packaged libraries), > re-building package every time. Right, that's what I figured. > The process is usually more tedious than complex but sometimes there > might be problems. Definitely feels tedious. :) >> Shouldn't we just remove *all* of vendor/? > > Ideally yes, but in practice we can not, at least not for the particular > package. Portion of Kubernetes is and few micro-libraries are not > provided by any package. Also there might be cases when Gitlab-Runner > won't build with anything we have but a vendored loibrary. Right, makes sense. >> I understand this is a somewhat sensitive issue, especially considering >> the recent Kubernetes discussions (which this is related to, because it >> does ship kubernetes glue code) > > It hasn't been a sensitive issue until controversial ruling by CTTE. > (To be honest I suspect there was unhealthy influence of a Kubernetes > insider on the committee but whatever). I am not sure I want to get into this debate, but I would argue that the ruling would have been considered controversial regardless of the outcome. :) (Also, I am not sure how productive it is to question the neutrality of the CTTE in this bug report, so I would refrain from that as well if I were you...) > We have _many_ packages with no "vendor" or partial vendoring > (e.g. syncthing, restic, consul, nomad, docker.io, libpod/podman > and its components, vault, etc.). And those are only few heavy ones I > could recall straight from my head. Heck, the most golang packages > have some or all vendored components removed in favour of packaged > libraries. That's just how we package Golang stuff. Yep, I've done a few myself! It generally works okay outside of the kubernetes world, because things are generally sane. ;) [...] > P.S. I already see that packaging 13.11.0 is going to be above average > effort. There are new FTBFS issues, some patches don't apply, etc... Yeah, for now I've switched to the upstream packages (in which I already found a bug - they don't ship /var/lib/gitlab-runner), which is a shame, but I really had to get this out the door and couldn't afford to run an older version. I hope my small amount of work will have been useful for you! Maybe I should have opened a bug report instead, too? Thanks! a. -- We will create a civilization of the Mind in Cyberspace. May it be more humane and fair than the world your governments have made before. - John Perry Barlow
