Subject: [bug#52109] [PATCH] gnu: Add unrar-free.

From: Leo Famulari <[email-masked]>
Date: Thu, 12 Jan 2023 18:07:14 -0500

On Thu, Jan 12, 2023 at 09:29:09PM +0100, Liliana Marie Prikler wrote:
> Now, I hope I'm not exaggerating when I say that most computer users
> use libarchive-based (un)archiving tools already. [3]
> Having observed this, I see little meaning in having a frontend, which
> per its name promises to open archives that their existing tooling
> can't handle, only to then reveal that it was the existing tooling all
> along.  If it didn't have the name that suggested it was able to do
> that, no one would expect it to, and upon encountering an archive that
> libarchive can't handle, they could go "well, fuck those rar guys, I
> have better things to do", or they could try and figure out what's
> wrong and contribute a fix (not that a fix is easily contributed given
> the nature of this bug, but somewhere along their journey they'd notice
> that rar is proprietary garbage and not fault libarchive too hard for
> not handling it).  Because unrar-free does have a name that suggests
> it's able to unrar those things, however, they will inevitably feel
> wronged no matter what and rather think "well, fuck unrar-free, I want
> unrar-nonfree".

In order to understand your points better, I'd like to summarize them in
my own words. Please tell me if I get it wrong.

Your objections to the inclusion of this package are that:

1) We already have a package with equivalent functionality
2) The name of this package, unrar-free, might lead users to choose a
nonfree program due to similarity. Concretely, the nonfree program is
called "unrar".

Is that correct?