On 2021-08-18 05:33:30, Anthony Fok wrote:
> Hi Antoine,
>
> On Tue, Aug 17, 2021 at 7:40 AM Antoine Beaupré <anar...@debian.org> wrote:
>>
>> On 2021-08-16 21:27:33, Anthony Fok wrote:
>>
>> [...]
>>
>> > So, in summary, it just means the following in debian/control:
>> >
>> > Source: github-cli
>> > ...
>> > XS-Go-Import-Path: github.com/github/cli
>> > ...
>> > Package: github-cli
>> > ...
>> > Conflicts: gitsome, gh
>> > Provides: gh
>> > Replaces: gh
>>
>> I do not see why you would Conflicts with `gh` here. It's not an actual
>> package name, so it doesn't need that. I am not sure that Replaces is
>> necessary either. Those would be required if we were renaming or
>> replacing an existing package, which is not quite the case here.
>
> That is because "gh" _is_ an actual Debian package name
> albeit not from official Debian sources.
> That is how GitHub has named their .deb packages, as seen in their
> latest release page here:
>
> https://github.com/cli/cli/releases/tag/v1.14.0
>
> As a matter of fact, I already have their GoRelease-generated
> gh_1.14.0_linux_arm64.deb installed because I couldn't wait. :-)
> Needed it for a work task at
> https://github.com/OpenDRR/opendrr-platform/issues/126
>
> Anyhow, since GitHub has already named their deb package "gh", it may
> be a good argument for us to name our official Debian package as "gh"
> too. (haha!)
>
> But anyhow, if we do decide to name our package "github-cli", the
> "Conflicts: gh" would allow me to smoothly upgrade from GitHub's "gh"
> deb package to Debian's "github-cli" deb package.
Oh, good point. This does seem like a good migration path then, although
I can't help but think we should collaborate with upstream in this case,
to make sure we converge over something instead of creating a confusing
pair of package names. It would be better for our users to have a
consistent naming with upstream...
>> Some would argue that installing gitsome *and* gh *would* be desirable,
>> however, which might make the Conflicts problematic. If that's the case,
>> then there is a number of mechanisms that we could use, but I'd actually
>> cross that bridge when we get there.
>
> Totally agreed.
> I find diversions somewhat messy, so I'd rather not go there
> unless someone actually starts complaining. :-)
Right, I would totally avoid diversions in general. I was thinking more
of "alternatives", and/or maybe splitting "gh" out of gitsome so that it
wouldn't have to conflict anymore.
a.
--
Treating different things the same can generate as much inequality as
treating the same things differently.
- Kimberlé Crenshaw
