gopass packaging status and possible improvements

[dominikschulz]

gopass is being independently packaged and maintained for a lot of different platforms.
Most linux distributions ship some kind of gopass package and we're even available on MacOS (homebrew) and Windows (Scoop, Chocolatey).

Most packages are regularly updated (at least the rolling release / bleading edge ones) but some lack considerably.
Maybe some distributions are missing a (proper) gopass package.

I would like to get a better understanding about the packaging status in the different package managers and what we can do make sure that our packages are in a great shape.

[AnomalRoil]

Mandatory link wrt. the topic:
https://repology.org/project/gopass/versions
To be noted that the Debian one is not our Gopass but another one.

[dominikschulz]

Thank you. I wanted to include that link in the issue.

Looking at the numbers in #1848 we can see that:

• Most downloads are for our Linux AMD64 binary builds
  • Note: These binary builds are also used by the self-updater
• The second largest downloads are for our Deb packages
• Homebrew shows significant usage, too

Note: We might have many more users who obtain gopass through their package manager, but those usually don't publish usage numbers.

Homebrew

gopass has an official tap in homebrew-core, that should be mostly fine.

However it's not using make install because of some problems with the man page: Homebrew/homebrew-core#73247. We should try to fix that. Using make install sets some build flags that would be nice to have. Filed #1852

Debian

Also: Ubuntu, Deepin, Devuan, Kali Linux, Pardus, Parrot, Raspbian

The situation of gopass on Debian-based distributions is very sad.

There is a gopass package available on these platforms and it's a pass-compatible implementation but it's not gopasspw/gopass but aviau/gopass.

I'll try to provide some context on this situation.

When we started the gopass project we were looking for a name and before settling on gopass we did check for conflicting projects. At this time there were no conflicting CLI tools or packages using that name.

The getpasswd implementation howeyc/gopass was already around but since that was a Go package and those are usually referrenced by their full import path we didn't see any issue with that.

What we did miss however was the Debian ITP (intent to package) bug #781494. This was already around when we released our first version, but the actual debian package wasn't uploaded until after gopass already gained some traction.

When we did first become aware of this naming conflict (shortly after it was uploaded to Debian unstable) I did reach out to the maintainer (who is also the upstream author) to suggest different options to resolve this confusion (e.g. not having a gopass package at all in debian but two similarly named ones or joining our efforts in one project) but they did not like either of my proposals and didn't respond very favorably.

It struck me as odd that they had an ITP sitting around for a few years and only started to publish a package after we had launched our gopass project (we tried to make a bit of fuzz around it, so it's not entriely unlikely that they became aware of that).

But nonetheless as far a my knowledge of the Debian Constitution and the Debian Policy goes I think package naming is first come first serve without any feasible conflict resolution approach. As such this is another example of poor Debian policies serving as an annoyance to it's users (cf. docker vs. docker.io).

I'm not sure if there is any way to improve this situation but I don't intent to spend any more time on this. If any of our users are unhappy about the situation I'd suggest they report to their distributions bug trackers.

But as a long time Debian user it makes me very sad :/

Others

Alpine Linux

They seem to accept PRs on their GitLab instance. I'm trying to see if they accept mine and if they are willing to we could automate updates to this in the future.

Arch

The community package seems to be pretty much up to date. I haven't figured out if they also accept PRs, but if they do we could automate that, too.

Chocolatey

Pretty much up to date, too. Not sure if this could be automated.

DPorts

Seems to be related to FreeBSD ports, quite outdated. But I have not idea how these work.

FreeBSD Ports

Up to date. Thanks!

Funtoo

Somewhat outdated. Is this a rolling release distro or not?

Gentoo

Up to date, Thanks!

MacPorts

Somewhat outdated.

Manjaro

Quite up to date, nice.

OpenBSD Ports

A little bit outdated.

Solus

Pretty much up to date. The maintainer has sent PRs to us. Thanks a lot!

Termux

A little bit outdated. They seem to accept PRs but we're in the termux/unstable-packages repo and require a patch on their side.

I'd like to make the patch obsolete and get us into their regular packages repo, if possible.

[dominikschulz]

Regarding the question if we can speed up adoption of new releases by e.g. sending PRs.

• Alpine Linux: Accepts PRs via https://gitlab.alpinelinux.org/alpine/aports
• Arch Linux: Not sure, likely not necessary.
• Chocolatey: Maybe
• FreeBSD: Using SVN ... 😨
• Gentoo: Maybe, likely not necessary
• Homebrew: Possible, but not necessary. They seem to be super fast already.
• LiGurOS develop: Not sure. Looks like it's a Gentoo derivate.
• Linuxbrew: Likely not necessary, see Homebrew
• MacPorts: Seems to accept PRs, package a little bit outdated.
• NixOS: Should be possible, but likely not necessary. They seem to be quite fast.
• OpenBSD Ports: Using SVN ... 😨
• Parabola Linux: Looks like a ArchLinux derivate
• Scoop: Possible, likey not necessary
• Solus: Not sure ...
• Termux: Not sure if they accept PRs, I have https://github.com/termux/unstable-packages/pull/214 open
• Void Linux: They seem to accept PRs, package slightly outdated.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[oliverpool]

Regarding debian, would it be possible to package it under a new name?
Like gopass-pw for instance?

It would greatly ease the installation process for those users (still not as ideal as gopass, but much better than the current manual steps).

[dominikschulz]

@oliverpool Yes, of course. But someone else needs to own that. I'm not going to waste my time arguing with Debian Maintainers anymore.

[dominikschulz]

Nothing to do here, I'd say. Apart from Debian this should be in good shape.