[PATCH] gnu: Add unrar-free.

---

gnu/packages/compression.scm | 31 +++++++++++++++++++++++++++++++

1 file changed, 31 insertions(+)

Hi,

Am Donnerstag, den 25.11.2021, 15:19 +0000 schrieb Foo Chuan Wei:

Does this program handle anything that libarchive does not already

have? libarchive already ships its own command line utility (bsdtar),

plus there's other frontends with less confusing names available. The

only use-case for "unrar-free" would be to inevitably push people

towards the non-free unrar when it inevitably fails to upack that one

of several weird rar files [1].

Cheers

[1] https://github.com/libarchive/libarchive/search?q=unrar&type=issues

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Since the program uses libarchive, it would think it supports the same

features as libarchive itself. Its value is in providing a simpler to

use front-end CLI.

While I appreciate your concern, I don't think it is a problem to have

unrar-free in GNU Guix; it is free software and respects the GNU FSDG,

as far as I can tell.

Thoughts?

--

Thanks,

Maxim

On 1/3/23 19:57, Maxim Cournoyer wrote:

Debian and Fedora, whose package guidelines are generally free-software

friendly (with some exceptions), include unrar-free.

Am Mittwoch, dem 04.01.2023 um 00:32 -0500 schrieb kiasoc5:

Neither Debian nor Fedora are recommended GNU distros. As for

Trisquel, which is, note how severely outdated the version there is.

More importantly,

Am Dienstag, dem 03.01.2023 um 19:57 -0500 schrieb Maxim Cournoyer:

Yes, the supported features are exactly the libarchive feature set.

However, I would argue that the value of providing this "simpler to use

front-end" is in fact a negative one. For one, bsdtar's CLI is not

that complicated, but what's more, some programs like file-roller

(which let's be honest, the uninitiated user is more likely to use than

either CLI) have an escape hatch for non-libarchive implementations of

unrar. Using this escape hatch to sneak in libarchive is plain silly

:)

Cheers

Hi,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

That it is present in Trisquel says a lot about its standing with FSDG.

I think arguing about how complicated alternatives are to use or whether

users should use such alternatives is beside the point. Guix contains

free software packages contributed by its contributors, not a curated

list of software that have been deemed useful or worthy based on the

opinions of the Guix committers/reviewers.

--

Thanks,

Maxim

On 1/4/23 14:41, Liliana Marie Prikler wrote:

They are not recommended for the inclusion of nonfree firmware but their

software packaging standards are free-software friendly.

Am Mittwoch, dem 04.01.2023 um 15:21 -0500 schrieb Maxim Cournoyer:

There are different interpretations of the FSDG. For instance, the

fact that we are downloading the blobby kernel and patching it is by

some regarded as iffy, but generally regarded as not an issue by Guix

people. Here, I'm using the point the FSDG raises with regards to

distributions about name confusion and apply it to software. Now

admittedly, that's a stretch, but one that makes me personally

uncomfortable if I'm told to sign off a commit that introduces such

software for – in my opinion – no good reason.

Cheers

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

I think unrar-free, if it makes libarchive easier to use via an

intuitive CLI, serves a purpose.

What we are discussing here is whether there's a problem or not with the

FSDG and the name 'unrar-free'. Given the argument that 'unrar-free'

package could steer users toward 'unrar' non-free (which is not

available in Guix) is a bit of a stretch (as you admitted), I don't

think it's ground to refuse its inclusion in Guix.

--

Thanks,

Maxim

Hi all,

On Tue, 10 Jan 2023 at 11:47, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

I agree with Maxim’s arguments. From my point of view, unrar-free

respects FSDG – and since it is present in Trisquel, I assume this

understanding of FSDG is shared – to some extent.

Even, I would say the Liliana’s opposite argument: it liberates user

from the non-free unrar by offering a free alternative. And it is the

case for all the free re-implementations, no?

Therefore, I do not see what is the blocker. :-)

Cheers,

simon

Am Mittwoch, dem 11.01.2023 um 23:31 +0100 schrieb zimoun:

From my point of view, it really doesn't. Now potentially, there's an

argument to be had that unrar-free acts as a "drop-in replacement" for

scripts, Makefiles etc. that assume the presence of the non-free unrar,

i.e. when you assume that you're bound to unrar's CLI. But(!)

libarchive already liberates you from that very CLI – perhaps not by

offering the exact same interface (which for the record unrar-nonfree

also doesn't), but by offering a program that can open some of the

archives (on top of handling zip, tar, etc.).  As for the actually

supported archives, they're the same for both CLIs, so no real

liberation is happening on that front.

Somewhat ironically, if unrar-free was using its own experimental

libarchive that has some patches it wishes to upstream, which improve

the handling of some RAR quirks, I wouldn't be as opposed to including

it. But as it stands right now, I see it as little more than a piece

of software that makes people go "but how do I get the _real_ unrar?",

cue people sending each other advice on a certain channel dedicated to

non-free software.

Cheers

Hello everybody,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

[...]

I also agree with _both_ Maxim arguments:

1. unrar-free is FSDG compliant, and I cannot see how this can be

defined "point of view" :-)

2. 'unrar-free' potentially steering users toward 'unrar' (non-free)

cannot be used as an argument to refuse 'unrar-free' inclusion in Guix

Liliana please reply to this two specific points, in particular please

tell us if you judge 'unrar-free' not to be FSDG compliant

[...]

(I don't understand "cue people": is it a misprint?)

OK I think you explained this argument very well and this goes under

point 2. above: 'unrar-free' potentially steering users toward 'unrar'

non-free

I'd say that all liberated versions of non-free software could make

people go "how do I get the _real_ one", no? For example Guix

distributed browsers are lacking EME implementation (no DRM loading) and

some other non-free "extensions" giving problems to users trying to use

certain web services; we have ungoogled-chromium and I know people

asking "how do I get the real Chrome"?

So, if I understand your last point, the problem you see is that

"unrar-free" (alone?) steers people to send each other advice on

channels including non-free software: could this be a reason not to

include a FSDG compliant software in Guix?

...or it's just it's name containing 'unrar'?

Cheers

--

Giovanni Biscuolo

Xelera IT Infrastructures

On Thu, Jan 12, 2023, at 01:22, Liliana Marie Prikler wrote:

This argument, whether or not it has merit on its own, has no precedent within Guix as a reason to exclude a free software program.

I'm sure most of us can name some Guix packages that we dislike because we see them in some unflattering or uncharitable way. But, we bite our tongues because Guix has a precedent of accepting freely licensed programs that are minimally functionally and not malware. Guix has had very liberal package acceptance criteria at least since I joined, if not since it began, and changing this precedent should require overwhelming consensus.

If there is a concrete objection (not conjecture or speculation) to this patch based on the criteria of the FSDG and precedents of Guix package acceptance, please share it. Otherwise, I think the patch should be accepted.

Am Donnerstag, dem 12.01.2023 um 08:36 +0100 schrieb Giovanni Biscuolo:

I already explained this in [1] but TL;DR, while it might be argued

that it follows the letter of the FSDG, my personal opinion is that it

does not follow the spirit.

Cue is a verb, which roughly means "to signal" or "to provoke" [2].

ungoogled-chromium is a bad example imho, because it's two steps

removed from Chrome. For one, there is the Chromium-Chrome split,

where the former prides itself on removing some of the Google cruft and

then you have ungoogled chromium on top of those patches to remove even

more cruft.

Perhaps not alone, you do need to also find one of those rar files that

can't be opened by libarchive, which are not that hard to come by.*

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".

The above feels like a very basic HCI thing to me, I wonder why it

takes like five mails to get across.

A free system distribution must not steer users towards obtaining any

nonfree information for practical use, or encourage them to do so. [4]

Cheers

such archives, but you'd also need them to create "normal" rar archives

¯\_(?)_/¯

[1] 9336884519247fe7c9a9cf0d532eb8a79b954a7f.camel@gmail.com

[2] https://en.wiktionary.org/wiki/cue#Verb

[3] https://github.com/libarchive/libarchive/wiki/LibarchiveUsers

[4]

Am Donnerstag, dem 12.01.2023 um 07:54 -0500 schrieb Leo Famulari:

For what it's worth, Guix also has a precedent of including things that

go against its own criteria due to reviewer oversight, be it bundled

libraries, both as source and blobs, or actually non-free software. In

my personal opinion, aiming to be a little more thorough doesn't hurt

that much :)

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

[...]

Strong language is not welcome here. Please make an effort to

keep it clean :-).

--

Thanks,

Maxim

On Thu, Jan 12, 2023 at 09:29:09PM +0100, Liliana Marie Prikler wrote:

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?

Am Donnerstag, dem 12.01.2023 um 18:07 -0500 schrieb Leo Famulari:

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

Hi Liliana,

On jeu., 12 janv. 2023 at 21:29, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

Liliana, it is *your* interpretation that unrar-free is–quoting

FSDG–“steering users toward obtaining any non-free information for

practical use, or encourage them to do so”. It is not the

interpretation of Trisquel folks. It is not my interpretation and

probably also not the interpretation of many other peers here.

For instance, a previous version of unrar had been added by commit,

0da8313c679f101c3f99970c50d6f0fef995f633

Author: John Darrington <jmd@gnu.org>

AuthorDate: Wed Mar 1 07:00:05 2017 +0100

Commit: John Darrington <jmd@gnu.org>

CommitDate: Wed Mar 1 18:57:00 2017 +0100

and then removed by 2560aa7adbfcb46306e8b19180bd48d39c2da6dc:

gnu: Remove unrar.

This package is abandoned upstream and contains serious bugs:

http://seclists.org/oss-sec/2017/q3/329

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14120

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14121

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14122

* gnu/packages/compression.scm (unrar): Remove variable.

Therefore, I am still missing what is blocking. ;-)

The fact that FSDG is poorly worded is one thing, indeed. This sentence

“steering users toward obtaining any non-free information for practical

use, or encourage them to do so” from these FSDG could also be

interpreted to many other features – another story. :-)

From my point of view, all the packages allowing interoperability across

various operating system (including non-free ones) fits my understanding

of the Liliana’s interpretation of “steer users toward obtaining any

non-free information for practical use, or encourage them to do so”;

interpretation mainly based – again, if I understand correctly – on

speculations about the user’s intention. Therefore, we should also

remove the packages: mednafen, docx2txt, antiword, bochs, cabextract,

cl-mssql, emacs-powershell, etc.

Any free reimplementation potentially offers a degraded experience

compared to the proprietary product. It does not appear to me an

argument to raise that this potentially degraded experience leads to

“steering users toward obtaining any non-free information for practical

use, or encourage them to do so”. Even, from my point of view, it is

the contrary: a free reimplementation even with weakness is liberating.

Last, I do not understand your Liliana argument about «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.». Well, we could apply it many

flavor of similar tools. For instance, you would be in favor to

remove/drop the CLI dulwich provided by the package python-dulwich since

CLI Dulwich user could just read the Git man pages. Or similarly bmake

vs make, coreutils vs busybox vs toybox, etc.

Without saying that I do not even know which Guix package provides this

bsdtar tool, from this FreeBSD tar manpage [1], it is not clear if RAR

is supported or not. To know it, one needs to open this other man page

[2]. Bah, yes an easy CLI matters!

All in all, it appears that we disagree. :-)

Cheers,

simon

1: https://www.freebsd.org/cgi/man.cgi?query=tar&sektion=1

2: https://www.freebsd.org/cgi/man.cgi?query=libarchive-formats&sektion=5&apropos=0&manpath=FreeBSD+13.1-RELEASE+and+Ports

Am Freitag, dem 13.01.2023 um 16:20 +0100 schrieb Simon Tournier:

I am aware of that and I pointed that out myself several times already.

I mean, I am not the only person, who can sign off commits here. I am

merely raising my own concerns w.r.t. this package and refusing to sign

off the commit myself – I am not hindering anyone else from picking it

up. Now, I can't exactly give you my written permission to do so, but

I will at least promise not to exercise my commit rights to revert it

without some more pressing issue (like the CVEs noted above).

Sure.

I fear your interpretation is made up of speculations of my intentions,

or in other words straw. I do argue however, that for most people when

they go seek out unrar-free, then it'd be because the archiver of their

choice failed them, in which case unrar-free won't be able to do

anything. Of the examples you list here, only cabextract is close in

spirit to unrar-free, with the difference that cabextract relies on the

CLI-less libmspack. If libmspack shipped with a CLI of its own that

handles cabs, I would argue that cabextract is pretty pointless, but

nonetheless it ironically doesn't even feature name confusion.

The thing is, you don't need unrar-free to get a degraded experience of

unpacking rar archives. Any libarchive-based archive manager will do,

most of which offer a more complete package.

If any of these packages were only offering alternative CLIs for

another tool while also inviting name confusion, yes, I would be in

favour of removing them. But that is not the case in any of the

examples you list here.

For the dulwich example, yes, it provides an alternative frontend to

git, but the value of that package is that it's a pure python

implementation of the git protocol, i.e. it doesn't use libgit.

(Interestingly, git is used as native input, presumably for testing

purposes.)

For bmake vs. GNU Make, I think that those are two different tools that

do the same job similar to clang and gcc both being C compilers. Now

removing clang because we have gcc would admittedly be pretty based,

but sadly not an option, because some programs depend on certain

implementation-defined behaviour of clang (and other parts of its

infrastructure).

For coreutils, busybox and toybox, these are again different

implementations of the same thing with slight variations. Now, based

on the controversial move of being GPL2 only, one could decide to

remove busybox in favour of the rollover-licensed toybox, but as it

stands I believe neither project steers users towards nonfree software

either by name or otherwise.

For contrast, the case we have with unrar-free is that we have a CLI in

libarchive (bsdtar) and a different CLI in unrar-free, both of which

use libarchive. This would be roughly equivalent to me making a new 

CLI frontend for wine and calling it pro^H^H^Hwin10.

I hazard a guess that you didn't have to unpack many RAR archives via

CLI then. Which fair enough, because there are other libarchive

frontends to further prove my point that unrar-free is not needed.

That it does :)

Cheers

On Thu, Nov 25, 2021 at 03:19:28PM +0000, Foo Chuan Wei wrote:

Thanks! Pushed as 949f88b1e5c1755a71c8b05b202c836f4161d36b. Then I

updated the package in a subsequent commit. Sorry for the ridiculous

delay.

Hi Liliana,

On ven., 13 janv. 2023 at 19:18, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

Your guess is incorrect. I unpack RAR archives via CLI using…

unrar-free from Debian – I collaborate with people running Windows where

RAR is very common.

Well, I just notice that even after this long thread, I do not still

know how to extract RAR archives using another tool than unrar-free.

Out of curiosity, how can I extract RAR archives using Guix without

unrar-free? Liliana, you mentioned BSDtar but “guix search” does not

return something relevant. Please, could you indicate me how to extract

RAR archives using Guix without unrar-free?

Cheers,

simon

Am Montag, dem 16.01.2023 um 10:46 +0100 schrieb Simon Tournier:

$ guix shell --pure libarchive -- bsdtar -xf $YOUR_ARCHIVE

In addition to that, note how file-roller, which comes with the default

GNOME setup, also handles RAR. You'd typically want it for its GUI,

but it can be invoked from the command line like

$ file-roller $YOUR_ARCHIVE -e $WHERE_TO_PUT_IT

Cheers

Hi Liliana,

On lun., 16 janv. 2023 at 14:56, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

Thanks. I will update libarchive description, if no one beats me.

Because it is far from clear that libarchive comes with these 3 binaries:

??? bin

?   ??? bsdcat

?   ??? bsdcpio

?   ??? bsdtar

Cheers,

simon

Hi Liliana,

On Mon, 16 Jan 2023 at 17:38, Simon Tournier <zimon.toutoune@gmail.com> wrote:

Please find attach the patch. :-) If it appears to you fine, could you

merge it?

Cheers,

simon

Am Samstag, dem 21.01.2023 um 17:09 +0100 schrieb zimoun:

Hmm, I fear that this line doesn't do much except helping folk to grep

for "bsdtar" et al. Should we perhaps explain in a sentence or two

what those commands do?

Hello Simon,

zimoun <zimon.toutoune@gmail.com> writes:

Nitpick, but I'd use "also provides the @command{bsdcat},

@command{bsdcpio} and @command{bsdtar} commands.", for the extra

eye-pleasing effect.

--

Thanks,

Maxim

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Either way is fine by me; if we want to summarize what these commands do

we could use a '@table @command' construct, I think.

--

Thanks,

Maxim

Hi Maxim,

On Sat, 21 Jan 2023 at 15:00, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

V2 attached.

Cheers,

simon

Hi,

On Sat, 21 Jan 2023 at 18:59, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

It is not ’grep’ but “guix search” so it is only an internal SEO. ;-)

From my point of view, some explanations about what these commands do

are done by the man pages.

Well, this trivial patch is just a quick workaround at 2 levels. One,

because Guix File Search [1] is almost done but not very popular yet.

Two, because this libarchive should be split into 2 different packages

or outputs: one for the library itself and another for the commands.

1: https://yhetil.org/guix/87pmd1r8kt.fsf@gmail.com

However, if a table containing what these utilities do seems

appropriated, here the description from the Debian package

’libarchive-tools’:

Cheers,

simon

Am Sonntag, dem 22.01.2023 um 16:09 +0100 schrieb zimoun:

Fair enough.

Splitting libarchive outputs is sadly a core-updates change, but we

could hide the existing one and add a user-facing one with the split if

that's what you desire. I don't think adding a package for just the

tools has merits.

I think these could be shortened as follows:

This package/the 'bin' output also provides

@itemize

@item @command{bsdtar} and @command{bsdcpio} to pack/unpack archives

like @command{tar} and @command{cpio} respectively, and

@item @command{bsdcat} to concatenate files like @command{cat} does,

while transparently unpacking archives.

@end itemize

WDYT?

Hi Simon,

zimoun <zimon.toutoune@gmail.com> writes:

Applied, with light modifications.

--

Thanks,

Maxim

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Like Simon, I think just mentioning the commands solve the lack of

discovery problem that they reported about these commands; the details

themselves can be further looked up by users via the manpages or --help

output, since the above description wouldn't provide much more than what

can be guessed already. I pushed Simon's suggested change.

--

Thanks,

Maxim

Hi Liliana,

On Sun, 22 Jan 2023 at 18:44, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

Well, I think the addition of a ’bin’ outputs would be the most

suitable, even if it is a core-updates change.

This table looks good to me. Although Maxim pushed the v2 (which I find

already enough :-)), it could be included for the package containing a

’bin’ outputs directed to core-updates. WDYT?

Cheers,

simon

Am Montag, dem 23.01.2023 um 08:45 +0100 schrieb zimoun:

I have no strong preference for either solution (with the other

solution being keeping the package as pushed by Maxim). If you think

we should do a bin output with that description, go for it.

Cheers