* Package name    : passage
   Version         : 1.7.4a2
   Upstream Contact: hi@filippo.io
* URL             : https://github.com/FiloSottile/passage
* License         : GPL-2+
   Programming Lang: Shell
   Description     : fork of password-store using age as encryption backend

passage stores passwords inside age encrypted files. This utility provides a
series of commands for manipulating the password store, allowing the user to
add, remove, edit, synchronize, generate, and manipulate passwords.

This package provides the same functionnality as password-store but uses age
instead of gpg, thus bringing to password management the security garanties of
this tool.

It depends on age and tree, with more functionnalities brought by git and
wl-clipboard or xclip.

I use it on a regular basis and am willing to maintain it alone as it does not
have much dependencies and consists mostly in a single shell script.

I actually already have the package ready, all i need now is an ITP bug number
so lintian will stop shouting at me I’m trying to create a new package not
solving an ITP bug, and some review: this is my first attempt to provide a
package for Debian.

The only issue I have left is that there is already a passage package in
Debian : https://packages.debian.org/sid/passage
Given my package comes afterwards, maybe I should rename it to
something else (ideas welcome). However, Alpine already packages this as
passage.

packages, this can create issues down the road if one is not
expericenced in Debian packaging quirks. (renaming src:passage also
breaks it's history in Debian tooling…)
It would be much cleaner to have a new name for the new package,
both binary and source.

Looking at passage:
Would it be a possiblity to see if the support for age could be
implemented in pass, the project passage forked from? This seems to
be the only difference, especially as upstream of passage doesn't look
quite active, last commit 1 year ago, and there are unanswered issues
and pull requests as well -- I fear it's development might have stalled
upstream, making the case for taking over the name "passage" weaker.

Le Sat, Oct 04, 2025 at 06:21:16PM +0200, Tobias Frost a écrit :

Do you have concrete examples about what could break following such a
renaming?

I’m not convinced passage (the video game) would lose anything from
being renamed, while passage (the command-line tool) would benefit a lot
from keeping the same command name that it has in all other
distributions.

We could rename only the launcher script, from /usr/games/passage to
/usr/games/passage-game, witout renaming the source package. Thus
keeping the benefit of calling the password manager from the expected
/usr/bin/passage command. But I fear this would bring more confusion,
with src:passage not providing a passage command, while
src:passage-password-manager would provide it.

---

This would indeed be the best way to handle that, assuming pass upstream
would be willing to maintain two distinct encryption backends.

To be clear, I was talking about ([source|binary]-)*package names*, not
binary (as in executables) names.

Regarding binary names, Policy §10.1 says you should consult the
debian-devel mailing list to soliciate input and find an solution.


For renaming the packages, I also suggest to discuss that on
debian-devel too. I would rename source packages, there be dragons
and Debian tooling is not made to cope well with renamed source and
taken over source packages, AFAIK.

One pratical thing is that passage (the game) is at version 4, while
passte (the tool) is at 1.x.x - which is lower. This would require an
epoch from the start (also required to be discussed on debian-devel)

So, I guess, you want to redirect this discussion to debian-devel.
Especially as there will be dragons - dragons myself has never heard of
before, even after a decade in the project.

(I did once, long long ago, a source package rename, I can't rememer
which package it was, I can't remember the actualy problems I
encountered, but I remember it was more painful than anticipated.)

Another option:
"passage" (the pass replacement) could possibly use "pass" as binary
name, as (with only taken a quick look at the package) the seem to be
compatible enough so that they are interchangeable -- one could even use
the alternatives system to even install both of them.

up the name for a new source package, just to align the name with
upstream.
That addtional take-over of the name for a new pacakge will be an
addtional challenge.

Le Mon, Oct 06, 2025 at 07:28:15PM +0200, Tobias Frost a écrit :

I really like that suggestion, as there is no reason to have both
available at the same time on a same system, and that would make a
transition between one and the other much easier.

Hoël, what do you think of that way to avoid the name collision for the
binary?

Am Mo, Okt 06, 2025 am 11:05:39 +0200 schrieb Antoine Le Gonidec:

I like the idea of using the alternatives system a lot. I’ll ensure the tools
are compatible enough and will try to come up with something.