"Loren M. Lang" <lor...@north-winds.org> writes: > On Tue, Jan 21, 2025 at 08:47:30AM +0100, Simon Josefsson wrote: >> Hi Loren, >> >> My 'sigstore-go' package has been in the NEW ftp-master queue for over >> 3 months but was finally accepted a couple of days ago. It pave the >> road for other tools like 'cosign', 'gitsign', etc. >> >> I think the policy is that for packages which contain command-line >> tools, they can be named after the upstream project. Like 'podman' or >> 'skopeo'. As far as I know, there is no process to rename a source >> package in Debian, so that is fairly complicated at this point. But >> the source package name should never influence anything important in my >> experience, so this is mostly a stylistic and namespace issue. What >> problem does it cause you? > > It is no serious problem. It's mostly to keep consistency and > standardization with the current Go Team policy and for my own OCD. :-) > It also might help someone trying to find it in the future if they are > expecting the standard naming and don't look too hard. I only suggest it > now because it appears that the package is only a couple days old in the > archive and has never been migrated to testing as far as I can tell. > However, it might be far more difficult than I imagine to do the rename > and not worth the effort as I've never looked into it. I also didn't > realize it had been in NEW for 3 months now. > > As far as the policy for this package, I am basing it on what I get from > dh-make-golang. This is the command I started with when I began bundling > this package a few days ago: > > dh-make-golang make -dep14 -git_revision v0.6.2 -type both \ > -upstream_git_history -wrap-and-sort ast github.com/sigstore/sigstore-go > > With -type prog, it will name it as sigstore-go, but with both or > library as the type, it uses the full module name.
Try '-type p+l' and you should get the source/binary package naming style I used. I think our policy is a bit unclear about naming binary+library projects. It says that for binary-only packages it should use the project name as the source package. It says to use the import path for binary+library packages but also refer to these as 'with the only purpose of building other Go programs for Debian'. So no case really apply to this scenario. Or I'm missing something. https://go-team.pages.debian.net/packaging.html#_binary_only_packages I think for Go packages that provide end-user facing command-line tools, it makes sense to use a source package name matching the upstream project name. Other parts of Debian like Python seems to struggle with the same naming consistency... /Simon > In any case, I've been able to install your -dev package and resume my > work updating the downstream package. Thanks for your work! >> >> Btw I share your frustration trying to find ITP for packages. It is >> easy to search for the wrong names and miss an existing ITP for the >> same package. This is because it is so clear what names Go packages >> use, is it the upstream repo name? The Go namespace name? The full >> path to the where the Go namespace lives within some repository? And >> the variations if a package happens to provide end-user tools. I don't >> think there is any reliable way to fix this, we just have to live with >> it. This isn't a Go specific problem, but the naming patterns used for >> Go make the problem worse. >> >> I would be happy if you and others work on and co-maintain this package >> with me, the Sigstore eco-system is fairly complex and it certainly can >> use help from more experience people. >> >> /Simon >> >> mån 2025-01-20 klockan 16:34 -0800 skrev Loren M. Lang: >> > Hello Simon and Go Team, >> > >> > I've been working on packaging a new module for Go over the last 3 >> > days >> > which is a dependency for another package I am trying to update. It >> > just >> > happens to be the sigstore-go module which is looks like you've >> > already >> > beat me to. I'm pretty sure it wasn't there 3 days ago when I looked >> > it >> > up in Apt. :-) >> > >> > I did check for an ITP first, but I only looked for the name >> > golang-github-sigstore-sigstore-go as it has a library component, not >> > sigstore-go and so missed it. It seems to be largely duplicate of my >> > own >> > efforts and already resolved the test suite issue with the upstream >> > package that I was still trying to fix. However, it does seem to >> > differ >> > in the standard practices for the recommended Go Team packaging model >> > with the source package and repo named as if it's a program-only >> > package. Would it be good to rename the source package now while it's >> > still young or is that too problematic? >> > >> > Also, thanks Simon for the work. It saves me from debugging the build >> > failures that was holding me back. >> > >> > Thanks, >>
signature.asc
Description: PGP signature
