I do not know how others have addressed this previously (thus far I have only been distributing this as binary tarballs and .deb packages uploaded to GitHub, as well as the rage binary crate on crates.io).

As fas as package naming goes, as long as the name includes rage then I don't have a strong care, but we should have a consistent fallback name to use where necessary.

Considered and rejected:

• rustage doesn't contain rage (and feels weird).
• ager nopenopenope 😝
• age-rs doesn't contain rage.
• rage-rs adds a redundant language indicator; if we're going to add a tag, it may as well be useful.
• rage-encrypt doesn't convey the right meaning (the tool can decrypt as well).

I think I'd suggest rage-encryption as a reasonable fallback:

• It conveys that it's related to encryption.
• It's close to the canonical URL https://age-encryption.org/
• It's a bit long, but users would only be typing that in once at install time).

As far as the binary goes, I would really prefer not to have the binaries renamed. How does the target linux distribution you are packaging for handle binary name conflicts?

[...]
Thank you very much for the answer!

As fas as package naming goes, as long as the name includes rage then I don't have a strong care, but we should have a consistent fallback name to use where necessary.
[...]

While building and packaging locally I came to the same conclusion that an
alternative name should keep starting with "rage".

In my current somehow working implementation I'm using "ragecrypt" as
package and binary name but this can be changed easily.
What is your opinion about this name?

With a small script I'm replacing most but not all references to "rage" with
"ragecrypt" in the source code.
Of course this might break on updates if upstream changes are somehow
incompatible with this script.

I think I'd suggest rage-encryption as a reasonable fallback:
[...]

With "rage-encryption" as package name I'm fine but if the binary name has
to be changed as well, it seems useful to keep both names in sync.

If the binary is not called "rage", something shorter than "rage-encryption" used
for both names might be preferred?

As far as the binary goes, I would really prefer not to have the binaries renamed. How does the target linux distribution you are packaging for handle binary name conflicts?

From this distribution point of view, as I understand it, the preferred
solution for software with different functionality but conflicting binary name is to

"Convince upstream to rename the binaries to something less generic (or just less conflicting)." [1]
;)

So, this is what I'm trying first and the downstream renaming is only
a fallback solution and probably not the most stable one.

If doing the later, it would be nice if at least the same fallback name is used
by different distributions and this is best decided and
coordinated by upstream in my opinion.

[1]
https://en.opensuse.org/openSUSE:Packaging_conflicts

"Convince upstream to rename the binaries to something less generic (or just less conflicting)." [1]

I'll rule this out right now: I will not be renaming the rage binary in this repository:

• I'm intentionally keeping close to the age binary (the reference Go implementation of this too, with an even more generic name), in naming and CLI usage.
• The primary installation pathway is cargo install rage, and I want that to match the primary binary name (for the same reason you are suggesting the package and binary being named the same).
• The primary audience of the rage binary is sysadmins, and I would not expect the servers they are administrating to ever have a media player installed, so the conflict would not occur. This is also a user base for which a succinct name is very beneficial.
• The secondary audience is regular users, but CLIs are not the best interface for them, and any GUI integration would not expose the name of the rage binary.

I'll have a bit more of a think about fallbacks. We definitely want something consistent, because even if the binary is not renamed here, OS integrations for example would need to be aware of the potential naming difference.

"Convince upstream to rename the binaries to something less generic (or just less conflicting)." [1]

I'll rule this out right now: I will not be renaming the rage binary in this repository:

Thank you for this clear and reasonable statement.
[...]
As packager I'll investigate which options remain:

• perhaps the media player package accepts a rename,

• adding explicit "Conflicts" statements to prevent parallel installation of
  both packages, keeping the binary but changing the package name,

• do not submit this package to the more "official" repositories,

• rename package and binary downstream as described previously.

If going the last route, I'll probably follow what you propose as
package/binary alternative name.
It would be nice if you (upstream) are aware of the renaming approach [2] and
perhaps you think of it doing source code changes touching strings with "rage"
included in the future.

I'll have a bit more of a think about fallbacks. We definitely want something consistent, because even if the binary is not renamed here, OS integrations for example would need to be aware of the potential naming difference.

Very appreciated that upstream considers possible downstream issues!

[2]
https://build.opensuse.org/package/view_file/home:cunix:rust/ragecrypt/name_string_replacement.sh

I appreciate the effort you're putting into finding a solution here 🙂 Program names are an inherently uncoordinated global namespace, that downstream package managers attempt to coalesce into their personal coordinated global namespace in a variety of different ways (e.g. Gentoo using category prefixes like app-crypt/age to reduce collisions, vs Debian's purely-global repository). I'd love to see better solutions for handling this at the package manager level, because it's not a scalable solution for maintainers to be doing individualised work for every conflicting package, of which there will be a multitude more than there are package managers.

If I had a magic wand to wave, my ideal scenario would be that the user installing the package could decide how to resolve this; if they tried to install both packages at once, the package manager would ask them which they want to refer to as rage, with both having fallbacks. I guess the closest to this for your target distribution is Conflicts, but it would be nice if there were a way for the user to pick a resolution rather than requiring "either-or".

hey @cunyx I'm trying to package rage again, and I'm not exactly going to ask either party to rename things! I think we can go with a name like rage-encryption for the package, and then we need to check to see if enlighnment has any file conflicts.

@str4d If the package "zypper install rage-encryption" was how it was done, that would be okay to you? The binary it installs would still be rage and rage-keygen.

EDIT: I'm going to add a conflicts to rage-encryption against rage, rage the media player is in a niche desktop env called enlightment and so I don't expect it to conflict. If it does happen, we'll deal with it when it comes up. The opensuse / suse product security teams are already happy with rage the encryption tool and we'll likely end up doing some code reviews in the future (and will of course keep str4d in the loop if we find anything!)

Yeah, I'm fine with rage-encryption as a fallback package name when the package manager hasn't built another form of domain separation. A little long, but it's a one-time operation per user, so I err on the side of clarity.

Excellent! In that case, did you want to put that on the readme.md so that other distros in the same boat as us also know what an appropriate alternative is too?

I figured that would naturally occur once there was a distro packaging it in this way, when I update the installation instructions 😁

@str4d rage-encryption has been accepted into openSUSE:Factory (what will be tumbleweed in a matter of days), and so I think this can be closed as "resolved" and the readme updated :)

Thanks again for your awesome work and for being so helpful! I'll try to help when I can in the future.