GNU bug report logs - #52109
[PATCH] gnu: Add unrar-free.

Previous Next

Full log

Message #56 received at 52109 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Leo Famulari <leo <at> famulari.name>
Cc: 52109 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>,
 zimoun <zimon.toutoune <at> gmail.com>, Giovanni Biscuolo <g <at> xelera.eu>,
 kiasoc5 <kiasoc5 <at> disroot.org>, Foo Chuan Wei <chuanwei.foo <at> hotmail.com>
Subject: Re: [bug#52109] [PATCH] gnu: Add unrar-free.
Date: Fri, 13 Jan 2023 06:19:19 +0100

Am Donnerstag, dem 12.01.2023 um 18:07 -0500 schrieb Leo Famulari:
> 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?
For the equivalence relation of "both being able to open the same
archives", yes.  Obviously, unrar-free has a different CLI – that's is
whole shtick, after all – but I'd argue that this doesn't matter,
because the people who prefer CLI over GUI know how to read manpages.

Cheers

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.