* Package name : forge Version : 0.4.0-1 Upstream Author : Andrew Nesbitt * URL : https://github.com/git-pkgs/forge * License : Expat Programming Lang: Go Description : Go library and CLI for working with git forges. Supports GitHub, GitLab, Gitea/Forgejo, and Bitbucket Cloud through a single interface. Go library and CLI for working with git forges. Supports GitHub, GitLab, Gitea/Forgejo, and Bitbucket Cloud through a single interface. https://salsa.debian.org/go-team/packages/forge https://salsa.debian.org/jas/forge/-/pipelines /Simon
retitle 1134655 ITP: forge-git -- library and CLI for working with git forges thanks I noticed Debian already has a source package called 'forge', so I am tentatively renaming this to 'forge-git' to avoid collision. The existing 'forge' package doesn't ship any binary package called 'forge' nor a /usr/bin/forge so I think the risk of collision here is low. However the 'snap' package do ship a /usr/bin/forge so we will have to think about that some. Raised discussion with upstream on this: https://github.com/git-pkgs/forge/issues/66 /Simon
[...] Beware that the BTS doesn't consistently separate source and binary package namespaces. I would advise not using the binary package name "forge" so long as that is also the name of a different source package. Ben.
Hi! This uses an extremely generic name for the package and program, please rename this (or ideally ask upstream in the existing ticket you filed) to something more unique. Thanks, Guillem
Guillem Jover [24/Apr 2:01pm +02] wrote: I agree, 'forge' is extremely generic.
Sean Whitton <spwhitton@spwhitton.name> writes: Agreed. And it is already used in Debian, so impossible to re-use: https://tracker.debian.org/pkg/forge What do people think would be a better name for the source package? Any objections to 'forge-git'? Sometimes names like 'forge-go' or 'forge-golang' is used, but I've always found them a bit ugly. I find 'forge-git' a bit more descriptive of what it does. Upstream replied and will not rename the project. I think shipping /usr/bin/forge with a Conflicts:snap (which also provides /usr/bin/forge) in a binary package 'forge' would be acceptable. Any objections? Renaming the binary names of upstream in Debian will be quite confusing, unless there is any consensus between RedHat/ArchLinux/Guix/etc to use the same non-upstream name. And I doubt we'll achieve that. Is there some other reasonable alternative? /Simon
Hi! This still seems extremely generic to me, it just combines the generic name with the VCS it supports, to me it would be similar to editor vs editor-txt (or something along those lines). That's rather unfortunate. :/ Yeah, I'm afraid this is not acceptable (see Debian Policy §10.1), neither for the binary package name nor the program name. And as has been mentioned makes the BTS very confusing when a binary package does not come from the source package with the same name. This could be brought up on distributions@lists.linux.dev, otherwise I guess the three other alternatives that come to mind, would be to either try to find another upstream project that provides similar functionality, fork with a better name, or not package it. :/ Thanks, Guillem
Guillem Jover <guillem@debian.org> writes:
Okay. How about 'golang-github-git-pkgs-forge' for the source package?
Is it this part you mean?
Two different packages must not install programs with different
functionality but with the same filenames. This also applies when
they are installed into different directories on the default (user
or root) PATH. (The case of two programs having the same
functionality but different implementations is handled via
“alternatives” or the “Conflicts” mechanism. See Maintainer Scripts
and Conflicting binary packages - Conflicts respectively.) If this
case happens, one of the programs must be renamed. The maintainers
should report this to the debian-devel mailing list and try to find
a consensus about which program will have to be renamed. If a
consensus cannot be reached, both programs must be renamed.
I'm not sure how important the /usr/bin/forge tool from the 'snap'
package is, and if it is possible to rename that, and asked upstream
about it:
https://github.com/KorfLab/SNAP/issues/24
Solving that wouldn't really solve the problem with the git-pkg-forge
package using a generic name, but it may improve things anyway. The
same arguments about /usr/bin/forge appears to be true for the existing
'snap' package too, unless I'm missing something.
Re the binary package name, I have some memory of badly named Go
packages that use a pattern like 'golang-github-git-pkgs-forge-tools'
for the CLI package. Any objections to that?
I seem to be hearing two different answers to this, or I am missing some
detail. I also thought the above situation would be a bad idea when
packaging 'git-merge-changelog' earlier:
https://lists.debian.org/debian-wnpp/2026/01/msg00004.html
I proceeded, and indeed things have worked without trouble (AFAICT) even
though 'git-merge-changelog' is now a source+binary package with the
same name as a binary from the 'gnulib' package.
Are these situations different somehow? Is there any written down real
explanation of the actual problem, and what the guidelines are? Any bug
reports discussing this?
Wouldn't you consider packaging the existing project but using a
different /usr/bin name acceptable? Many Debian packages are like that
already.
/Simon
Simon Josefsson [28/Apr 8:54am +02] wrote: snap doesn't actually install /usr/bin/forge, right? It can just be used to install a snap which occupies /usr/bin/forge? In that case it's not clear that Policy cleanly applies but I would be in favour of interpreting Policy broadly here.
No, I'm talking about the 'snap' source package: https://tracker.debian.org/pkg/snap It builds a binary package 'snap' that provides /usr/bin/forge: https://packages.debian.org/sid/amd64/snap/filelist /Simon
Simon Josefsson [28/Apr 11:26am +02] wrote: Apologies, I messed up my apt-file invocation.