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.
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,
>
--
Loren M. Lang
lorenl@north-winds.org
http://www.north-winds.org/
IRC: penguin359
Public Key: http://www.north-winds.org/lorenl_pubkey.asc
Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA
Attachment:
signature.asc
Description: PGP signature