"Loren M. Lang" <lor...@north-winds.org> writes: > On Tue, Jan 21, 2025 at 02:45:35PM +0100, Simon Josefsson wrote: >> "Loren M. Lang" <lor...@north-winds.org> writes: > >> > 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. >> > > Interesting, I didn't realize it had both a p+l and l+p configuration. > Also, since I wrote that email, I've now run into other packages that > used the p+l configuration. Interesting though the aliases that they > added for them, both is l+p but combined is p+l. I'm curious if there is > a consensus from the Go Team on which case one is better than the other.
I'm also curious about this. My approach has been to prefer "p+l" (combined) when the binary package are more likely to be relevant as a interactively used end-user tool (such as 'podman', 'skopep, 'cosign' etc) and prefer "l+p" (both) when the binary packages are less likely to be relevant as interactive end-user tools (such as build tools like protoc plugins). But there are many exceptions and inconsistency on this. I think that is typical for anything related to naming though. /Simon
signature.asc
Description: PGP signature
