Re: Bug#1134655: ITP: forge -- Go library and CLI for working with git forges. Supports GitHub, GitLab, Gitea/Forgejo, and Bitbucket Cloud through a single interface.

Simon Josefsson <[email protected]> Tue, 28 Apr 2026 08:54:59 +0200
Newsgroups	gmane.linux.debian.devel.general
Message-ID	<[email protected]>
Guillem Jover <[email protected]> writes:

> Hi!
>
> On Mon, 2026-04-27 at 23:00:09 +0200, Simon Josefsson wrote:
>> Sean Whitton <[email protected]> writes:
>> > Guillem Jover [24/Apr  2:01pm +02] wrote:
>> >> 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.
>> >
>> > I agree, 'forge' is extremely generic.
>
>> 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'?
>
> 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).

Okay.  How about 'golang-github-git-pkgs-forge' for the source package?

>> 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?
>
> Yeah, I'm afraid this is not acceptable (see Debian Policy §10.1),
> neither for the binary package name nor the program name.

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?

> 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.

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?

>> 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?
>
> This could be brought up on [email protected], 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. :/

Wouldn't you consider packaging the existing project but using a
different /usr/bin name acceptable?  Many Debian packages are like that
already.

/Simon
signature.asc (application/pgp-signature, 1.2 KB)