Otto Kekäläinen <otto@debian.org> writes: > Hi! > > I filed the estimate bug at https://github.com/Debian/dh-make-golang/issues/231 > > This command I had not tried before turned out very useful: > > # dh-make-golang check-depends > NEW dependency github.com/charmbracelet/lipgloss > (golang-github-charmbracelet-lipgloss-dev) > NEW dependency github.com/charmbracelet/x (golang-github-charmbracelet-x-dev) > NEW dependency github.com/charmbracelet/x (golang-github-charmbracelet-x-dev) > NEW dependency golang.org/x/term (golang-golang-x-term-dev) > RM dependency (golang-github-olekukonko-tablewriter-dev) > > It might make sense to run this command in CI +1 > and fail the job if this command prints any output (or modify it to > give an exit code unless dependencies are clean). The tool is too fragile for this, for many packages there will be false positives or false negatives due to naming issues. > Also, this tool does only look at package names, it does not seem to > compare version numbers and point out if any of the existing packages > in Debian are too old and need to be updated. Seems I need to do that > for 3 packages. That in turn leads down another rabbit hole, as > updating these libraries need to be tested for compatibility with > existing packages, and a quick rdepends test build on e.g. > https://salsa.debian.org/otto/golang-github-charmbracelet-glamour/-/pipelines/770887 > shows that the new version broke every single package that depended on > it :( > > Anyway, I got eventually two new dependencies packaged and three old > ones updated. With a little additional patching of Glow I finally got > it build in unstable. I will test it out from my PPA for a couple of > days and then plan how to proceed with reviews and uploads > (https://launchpad.net/~otto/+archive/ubuntu/ppa?field.series_filter=plucky). Do you rebuild all reverse dependencies of packages you update? I do it using a reverse Salsa build pipeline, but I think ratt is the recommended approach. I've found that this is the single most annoying thing with Go packages in Debian: updating one package often trigger FTBFS bugs in other packages, and you need to check for this before uploads because the FTBFS cycle can be 10+ packages long and require changes in multiple packages, and can potentially be impossible to fix without upstream patching (which takes time to resolve), and the dependency chain can even be circular back to an earlier version of the package you wanted to update. Leaving FTBFS bugs open until the entire dependency chain has been resolved is not acceptable either, as that may just trigger testing removal of 100+ packages. This is different from most other packages in Debian: you just upload a new upstream release and resolve the problems triggered in other packages separately. /Simon
Attachment:
signature.asc
Description: PGP signature