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

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

[Foo Chuan Wei]

* gnu/packages/compression.scm (unrar-free): New variable.
---
 gnu/packages/compression.scm | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/gnu/packages/compression.scm b/gnu/packages/compression.scm
index 0a993d1550..deef04a1b1 100644
--- a/gnu/packages/compression.scm
+++ b/gnu/packages/compression.scm
@@ -33,6 +33,7 @@
 ;;; Copyright © 2021 Antoine Côté <antoine.cote@posteo.net>
 ;;; Copyright © 2021 Vincent Legoll <vincent.legoll@gmail.com>
 ;;; Copyright © 2021 Maxim Cournoyer <maxim.cournoyer@gmail.com>
+;;; Copyright © 2021 Foo Chuan Wei <chuanwei.foo@hotmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -2715,6 +2716,36 @@ compression and decompression.  The supported formats are:
 ")
     (license license:expat)))
 
+(define-public unrar-free
+  (package
+    (name "unrar-free")
+    (version "0.1.1")
+    (source
+     (origin
+       (method git-fetch)
+       (uri (git-reference
+             (url "https://gitlab.com/bgermann/unrar-free")
+             (commit version)))
+       (file-name (git-file-name name version))
+       (sha256
+        (base32 "0l9xdygk8ki8471lmg8xkb58zq07cb9hy44pqz1hlyhgsvrb6vss"))))
+    (build-system gnu-build-system)
+    (inputs
+     `(("libarchive" ,libarchive)))
+    (native-inputs
+     `(("autoconf" ,autoconf)
+       ("automake" ,automake)
+       ("pkg-config" ,pkg-config)))
+    (home-page "https://gitlab.com/bgermann/unrar-free")
+    (synopsis "Extract files from RAR archives")
+    (description
+     "@code{unrar-free} is a free software version of the non-free @code{unrar}
+utility.  This program is a simple command-line front-end to libarchive, and can
+list and extract not only RAR archives but also other formats supported by
+libarchive.  It does not rival the non-free @code{unrar} in terms of features,
+but special care has been taken to ensure it meets most user's needs.")
+    (license license:gpl2+)))
+
 (define-public tarlz
   (package
     (name "tarlz")

base-commit: ea7233befb9570cce47e5ca71725b285a580cd22
-- 
2.25.1

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

[Liliana Marie Prikler]

Hi,

Am Donnerstag, den 25.11.2021, 15:19 +0000 schrieb Foo Chuan Wei:
> * gnu/packages/compression.scm (unrar-free): New variable.
> [...]
> +    (inputs
> +     `(("libarchive" ,libarchive)))
> [...] 
> This program is a simple command-line front-end to libarchive
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

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

[Maxim Cournoyer]

Hi Liliana,

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

> Hi,
>
> Am Donnerstag, den 25.11.2021, 15:19 +0000 schrieb Foo Chuan Wei:
>> * gnu/packages/compression.scm (unrar-free): New variable.
>> [...]
>> +    (inputs
>> +     `(("libarchive" ,libarchive)))
>> [...] 
>> This program is a simple command-line front-end to libarchive
> 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].

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

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

[kiasoc5 via Guix-patches via]

On 1/3/23 19:57, Maxim Cournoyer wrote:
>
> 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
Debian and Fedora, whose package guidelines are generally free-software 
friendly (with some exceptions), include unrar-free.

https://repology.org/project/unrar-free/versions

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

[Liliana Marie Prikler]

Am Mittwoch, dem 04.01.2023 um 00:32 -0500 schrieb kiasoc5:
> On 1/3/23 19:57, Maxim Cournoyer wrote:
> > 
> > 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
> Debian and Fedora, whose package guidelines are generally free-
> software friendly (with some exceptions), include unrar-free.
> 
> https://repology.org/project/unrar-free/versions
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:
> 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.

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

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

[Maxim Cournoyer]

Hi,

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

> Am Mittwoch, dem 04.01.2023 um 00:32 -0500 schrieb kiasoc5:
>> On 1/3/23 19:57, Maxim Cournoyer wrote:
>> > 
>> > 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
>> Debian and Fedora, whose package guidelines are generally free-
>> software friendly (with some exceptions), include unrar-free.
>> 
>> https://repology.org/project/unrar-free/versions
> Neither Debian nor Fedora are recommended GNU distros.  As for
> Trisquel, which is, note how severely outdated the version there is.

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

> More importantly,
>
> Am Dienstag, dem 03.01.2023 um 19:57 -0500 schrieb Maxim Cournoyer:
>> 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.
>
> 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
> :)

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

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

[kiasoc5 via Guix-patches via]

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

> Neither Debian nor Fedora are recommended GNU distros.

They are not recommended for the inclusion of nonfree firmware but their 
software packaging standards are free-software friendly.

https://www.gnu.org/distros/common-distros.html

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

[Liliana Marie Prikler]

Am Mittwoch, dem 04.01.2023 um 15:21 -0500 schrieb Maxim Cournoyer:
> Hi,
> 
> That it is present in Trisquel says a lot about its standing with
> FSDG.
> 
> [...] 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.
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

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

[Maxim Cournoyer]

Hi Liliana,

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

> Am Mittwoch, dem 04.01.2023 um 15:21 -0500 schrieb Maxim Cournoyer:
>> Hi,
>> 
>> That it is present in Trisquel says a lot about its standing with
>> FSDG.
>> 
>> [...] 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.

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

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

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

[zimoun]

Hi all,

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

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

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

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

[Liliana Marie Prikler]

Am Mittwoch, dem 11.01.2023 um 23:31 +0100 schrieb zimoun:
> Hi all,
> 
> On Tue, 10 Jan 2023 at 11:47, Maxim Cournoyer
> <maxim.cournoyer@gmail.com> wrote:
> 
> > 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.
> 
> 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?
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

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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 2238 bytes --]

Hello everybody,

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

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

[...]

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

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

>> 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?
> From my point of view, it really doesn't.

[...]

> 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?",

(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"?

> cue people sending each other advice on a certain channel dedicated to
> non-free software.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

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

[Leo Famulari]

On Thu, Jan 12, 2023, at 01:22, Liliana Marie Prikler wrote:
> 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?",

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.

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

[Liliana Marie Prikler]

Am Donnerstag, dem 12.01.2023 um 08:36 +0100 schrieb Giovanni Biscuolo:
> Hello everybody,
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
> > Am Mittwoch, dem 11.01.2023 um 23:31 +0100 schrieb zimoun:
> 
> [...]
> 
> > > 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.
> 
> 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 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. 

> > > 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?
> > From my point of view, it really doesn't.
> 
> [...]
> 
> > 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?",
> 
> (I don't understand "cue people": is it a misprint?)
Cue is a verb, which roughly means "to signal" or "to provoke" [2].


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

> > cue people sending each other advice on a certain channel dedicated
> > to non-free software.
> 
> 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: 
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.

> could this be a reason not to include a FSDG compliant software in
> Guix?
A free system distribution must not steer users towards obtaining any
nonfree information for practical use, or encourage them to do so. [4]

Cheers


* Admittedly, you still have to make use of nonfree software to create
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]
https://www.gnu.org/distros/free-system-distribution-guidelines.html

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

[Liliana Marie Prikler]

Am Donnerstag, dem 12.01.2023 um 07:54 -0500 schrieb Leo Famulari:
> On Thu, Jan 12, 2023, at 01:22, Liliana Marie Prikler wrote:
> > 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?",
> 
> 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.
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 :)

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

[Maxim Cournoyer]

Hi Liliana,

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

[...]

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

Strong language is not welcome here.  Please make an effort to
keep it clean :-).

-- 
Thanks,
Maxim

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

[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?

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

[Liliana Marie Prikler]

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

[bug#52109] How to resolve? (Re: [bug#52109] [PATCH] gnu: Add unrar-free.)

[Simon Tournier]

Hi Liliana,

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

>> could this be a reason not to include a FSDG compliant software in
>> Guix?
>
> A free system distribution must not steer users towards obtaining any
> nonfree information for practical use, or encourage them to do so. [4]

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>

[bug#52109] How to resolve? (Re: [bug#52109] [PATCH] gnu: Add unrar-free.)

[Liliana Marie Prikler]

Am Freitag, dem 13.01.2023 um 16:20 +0100 schrieb Simon Tournier:
> Hi Liliana,
> 
> On jeu., 12 janv. 2023 at 21:29, Liliana Marie Prikler
> <liliana.prikler@gmail.com> wrote:
> 
> > > could this be a reason not to include a FSDG compliant software
> > > in Guix?
> > 
> > A free system distribution must not steer users towards obtaining
> > any nonfree information for practical use, or encourage them to do
> > so. [4]
> 
> 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.
I am aware of that and I pointed that out myself several times already.

> 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. ;-)
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).

> 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. :-)
Sure.

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

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

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

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

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


Cheers

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

[Leo Famulari]

On Thu, Nov 25, 2021 at 03:19:28PM +0000, Foo Chuan Wei wrote:
> * gnu/packages/compression.scm (unrar-free): New variable.

Thanks! Pushed as 949f88b1e5c1755a71c8b05b202c836f4161d36b. Then I
updated the package in a subsequent commit. Sorry for the ridiculous
delay.

> ---
>  gnu/packages/compression.scm | 31 +++++++++++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/gnu/packages/compression.scm b/gnu/packages/compression.scm
> index 0a993d1550..deef04a1b1 100644
> --- a/gnu/packages/compression.scm
> +++ b/gnu/packages/compression.scm
> @@ -33,6 +33,7 @@
>  ;;; Copyright © 2021 Antoine Côté <antoine.cote@posteo.net>
>  ;;; Copyright © 2021 Vincent Legoll <vincent.legoll@gmail.com>
>  ;;; Copyright © 2021 Maxim Cournoyer <maxim.cournoyer@gmail.com>
> +;;; Copyright © 2021 Foo Chuan Wei <chuanwei.foo@hotmail.com>
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -2715,6 +2716,36 @@ compression and decompression.  The supported formats are:
>  ")
>      (license license:expat)))
>  
> +(define-public unrar-free
> +  (package
> +    (name "unrar-free")
> +    (version "0.1.1")
> +    (source
> +     (origin
> +       (method git-fetch)
> +       (uri (git-reference
> +             (url "https://gitlab.com/bgermann/unrar-free")
> +             (commit version)))
> +       (file-name (git-file-name name version))
> +       (sha256
> +        (base32 "0l9xdygk8ki8471lmg8xkb58zq07cb9hy44pqz1hlyhgsvrb6vss"))))
> +    (build-system gnu-build-system)
> +    (inputs
> +     `(("libarchive" ,libarchive)))
> +    (native-inputs
> +     `(("autoconf" ,autoconf)
> +       ("automake" ,automake)
> +       ("pkg-config" ,pkg-config)))
> +    (home-page "https://gitlab.com/bgermann/unrar-free")
> +    (synopsis "Extract files from RAR archives")
> +    (description
> +     "@code{unrar-free} is a free software version of the non-free @code{unrar}
> +utility.  This program is a simple command-line front-end to libarchive, and can
> +list and extract not only RAR archives but also other formats supported by
> +libarchive.  It does not rival the non-free @code{unrar} in terms of features,
> +but special care has been taken to ensure it meets most user's needs.")
> +    (license license:gpl2+)))
> +
>  (define-public tarlz
>    (package
>      (name "tarlz")
> 
> base-commit: ea7233befb9570cce47e5ca71725b285a580cd22
> -- 
> 2.25.1
> 
> 
> 
> 

[bug#52109] How to resolve? (Re: [bug#52109] [PATCH] gnu: Add unrar-free.)

[Simon Tournier]

Hi Liliana,

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

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

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

[bug#52109] How to resolve? (Re: [bug#52109] [PATCH] gnu: Add unrar-free.)

[Liliana Marie Prikler]

Am Montag, dem 16.01.2023 um 10:46 +0100 schrieb Simon Tournier:
> Hi Liliana,
> 
> On ven., 13 janv. 2023 at 19:18, Liliana Marie Prikler
> <liliana.prikler@gmail.com> wrote:
> 
> > 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.
> 
> 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?
$ 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

[bug#52109] How to resolve? (Re: [bug#52109] [PATCH] gnu: Add unrar-free.)

[Simon Tournier]

Hi Liliana,

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

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

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

[bug#52109] Mention bsdcat, bsdcpio and bsdtar in description of libarchive

[zimoun]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

Hi Liliana,

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

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

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

Cheers,
simon



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: p.patch --]
[-- Type: text/x-diff, Size: 1159 bytes --]

From 6947165af4e53821662049aac847a50fc470c49e Mon Sep 17 00:00:00 2001
From: Simon Tournier <zimon.toutoune@gmail.com>
Date: Sat, 21 Jan 2023 17:04:56 +0100
Subject: [PATCH] gnu: libarchive: Mention bsdcat, bsdcpio and bsdtar in
 description.

* gnu/packages/backup.scm (libarchive)[description]: Mention the utilities
bsdcat, bsdcpio and bsdtar.
---
 gnu/packages/backup.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/backup.scm b/gnu/packages/backup.scm
index 8e629c2592..7e8282da20 100644
--- a/gnu/packages/backup.scm
+++ b/gnu/packages/backup.scm
@@ -333,7 +333,9 @@ (define-public libarchive
 as gzip and bzip2.  The library is inherently stream-oriented; readers
 serially iterate through the archive, writers serially add things to the
 archive.  In particular, note that there is currently no built-in support for
-random access nor for in-place modification.")
+random access nor for in-place modification.
+
+This package also provides the three utilities bsdcat, bsdcpio and bsdtar.")
     (license license:bsd-2)))
 
 (define-public rdup

base-commit: 900d33527c9286a811f064d4bb8f4a9b18d1db0b
-- 
2.38.1

[bug#52109] Mention bsdcat, bsdcpio and bsdtar in description of libarchive

[Liliana Marie Prikler]

Am Samstag, dem 21.01.2023 um 17:09 +0100 schrieb zimoun:
> Hi Liliana,
> 
> On Mon, 16 Jan 2023 at 17:38, Simon Tournier
> <zimon.toutoune@gmail.com> wrote:
> 
> > Thanks.  I will update libarchive description, if no one beats me.
> 
> Please find attach the patch. :-)  If it appears to you fine, could
> you merge it?
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?

[bug#52109] Mention bsdcat, bsdcpio and bsdtar in description of libarchive

[Maxim Cournoyer]

Hello Simon,

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

> Hi Liliana,
>
> On Mon, 16 Jan 2023 at 17:38, Simon Tournier <zimon.toutoune@gmail.com> wrote:
>
>> Thanks.  I will update libarchive description, if no one beats me.
>
> Please find attach the patch. :-)  If it appears to you fine, could you
> merge it?
>
> Cheers,
> simon
>
>
> From 6947165af4e53821662049aac847a50fc470c49e Mon Sep 17 00:00:00 2001
> From: Simon Tournier <zimon.toutoune@gmail.com>
> Date: Sat, 21 Jan 2023 17:04:56 +0100
> Subject: [PATCH] gnu: libarchive: Mention bsdcat, bsdcpio and bsdtar in
>  description.
>
> * gnu/packages/backup.scm (libarchive)[description]: Mention the utilities
> bsdcat, bsdcpio and bsdtar.
> ---
>  gnu/packages/backup.scm | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/backup.scm b/gnu/packages/backup.scm
> index 8e629c2592..7e8282da20 100644
> --- a/gnu/packages/backup.scm
> +++ b/gnu/packages/backup.scm
> @@ -333,7 +333,9 @@ (define-public libarchive
>  as gzip and bzip2.  The library is inherently stream-oriented; readers
>  serially iterate through the archive, writers serially add things to the
>  archive.  In particular, note that there is currently no built-in support for
> -random access nor for in-place modification.")
> +random access nor for in-place modification.
> +
> +This package also provides the three utilities bsdcat, bsdcpio and bsdtar.")
>      (license license:bsd-2)))
>  

Nitpick, but I'd use "also provides the @command{bsdcat},
@command{bsdcpio} and @command{bsdtar} commands.", for the extra
eye-pleasing effect.

-- 
Thanks,
Maxim

[bug#52109] Mention bsdcat, bsdcpio and bsdtar in description of libarchive

[Maxim Cournoyer]

Hi Liliana,

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

> Am Samstag, dem 21.01.2023 um 17:09 +0100 schrieb zimoun:
>> Hi Liliana,
>> 
>> On Mon, 16 Jan 2023 at 17:38, Simon Tournier
>> <zimon.toutoune@gmail.com> wrote:
>> 
>> > Thanks.  I will update libarchive description, if no one beats me.
>> 
>> Please find attach the patch. :-)  If it appears to you fine, could
>> you merge it?
> 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?

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

[bug#52109] Mention bsdcat, bsdcpio and bsdtar in description of libarchive

[zimoun]

[-- Attachment #1: Type: text/plain, Size: 273 bytes --]

Hi Maxim,

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

> Nitpick, but I'd use "also provides the @command{bsdcat},
> @command{bsdcpio} and @command{bsdtar} commands.", for the extra
> eye-pleasing effect.

V2 attached.

Cheers,
simon


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: v2.patch --]
[-- Type: text/x-diff, Size: 1188 bytes --]

From 1f7ad76468644456dc5fc3cf52de52521f2b35b8 Mon Sep 17 00:00:00 2001
From: Simon Tournier <zimon.toutoune@gmail.com>
Date: Sat, 21 Jan 2023 17:04:56 +0100
Subject: [PATCH v2] gnu: libarchive: Mention bsdcat, bsdcpio and bsdtar in
 description.

* gnu/packages/backup.scm (libarchive)[description]: Mention the utilities
bsdcat, bsdcpio and bsdtar.
---
 gnu/packages/backup.scm | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/backup.scm b/gnu/packages/backup.scm
index 8e629c2592..f3fba4ae50 100644
--- a/gnu/packages/backup.scm
+++ b/gnu/packages/backup.scm
@@ -333,7 +333,10 @@ (define-public libarchive
 as gzip and bzip2.  The library is inherently stream-oriented; readers
 serially iterate through the archive, writers serially add things to the
 archive.  In particular, note that there is currently no built-in support for
-random access nor for in-place modification.")
+random access nor for in-place modification.
+
+This package also provides the @command{bsdcat}, @command{bsdcpio} and
+@command{bsdtar} commands.")
     (license license:bsd-2)))
 
 (define-public rdup

base-commit: 3174affaf436f06d0c1ed2a8db2c524a29010bbb
-- 
2.38.1

[bug#52109] Mention bsdcat, bsdcpio and bsdtar in description of libarchive

[zimoun]

Hi,

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

>> Please find attach the patch. :-)  If it appears to you fine, could
>> you merge it?
>
> 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?

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’:

--8<---------------cut here---------------start------------->8---
The bsdtar program is the default system 'tar' program used on
FreeBSD. bsdtar uses the libarchive library as a backend which does all
of the work for reading and writing archives in various formats.

The bsdcpio program is the default system 'cpio' program used on
FreeBSD. bsdcpio uses the libarchive library as a backend which does all
of the work for reading and writing archives in various formats

The bsdcat program reads archived data from files or from its standard
input and uses the libarchive library to decompresses it to its standard
output. It may be used for viewing the contents of archives or for
passing it to other tools for further processing.
--8<---------------cut here---------------end--------------->8---

Cheers,
simon

[bug#52109] Mention bsdcat, bsdcpio and bsdtar in description of libarchive

[Liliana Marie Prikler]

Am Sonntag, dem 22.01.2023 um 16:09 +0100 schrieb zimoun:
> Hi,
> 
> On Sat, 21 Jan 2023 at 18:59, Liliana Marie Prikler
> <liliana.prikler@gmail.com> wrote:
> 
> > > Please find attach the patch. :-)  If it appears to you fine,
> > > could you merge it?
> > 
> > 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?
> 
> 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.
Fair enough.

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

> However, if a table containing what these utilities do seems
> appropriated, here the description from the Debian package
> ’libarchive-tools’:
> 
> --8<---------------cut here---------------start------------->8---
> The bsdtar program is the default system 'tar' program used on
> FreeBSD. bsdtar uses the libarchive library as a backend which does
> all of the work for reading and writing archives in various formats.
> 
> The bsdcpio program is the default system 'cpio' program used on
> FreeBSD. bsdcpio uses the libarchive library as a backend which does
> all of the work for reading and writing archives in various formats
> 
> The bsdcat program reads archived data from files or from its
> standard input and uses the libarchive library to decompresses it to
> its standard output. It may be used for viewing the contents of
> archives or for passing it to other tools for further processing.
> --8<---------------cut here---------------end--------------->8---
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?

[bug#52109] Mention bsdcat, bsdcpio and bsdtar in description of libarchive

[Maxim Cournoyer]

Hi Simon,

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

> Hi Maxim,
>
> On Sat, 21 Jan 2023 at 15:00, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>
>> Nitpick, but I'd use "also provides the @command{bsdcat},
>> @command{bsdcpio} and @command{bsdtar} commands.", for the extra
>> eye-pleasing effect.
>
> V2 attached.
>
> Cheers,
> simon
>
> From 1f7ad76468644456dc5fc3cf52de52521f2b35b8 Mon Sep 17 00:00:00 2001
> From: Simon Tournier <zimon.toutoune@gmail.com>
> Date: Sat, 21 Jan 2023 17:04:56 +0100
> Subject: [PATCH v2] gnu: libarchive: Mention bsdcat, bsdcpio and bsdtar in
>  description.

Applied, with light modifications.

-- 
Thanks,
Maxim

[bug#52109] Mention bsdcat, bsdcpio and bsdtar in description of libarchive

[Maxim Cournoyer]

Hi Liliana,

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

> Am Sonntag, dem 22.01.2023 um 16:09 +0100 schrieb zimoun:
>> Hi,
>> 
>> On Sat, 21 Jan 2023 at 18:59, Liliana Marie Prikler
>> <liliana.prikler@gmail.com> wrote:
>> 
>> > > Please find attach the patch. :-)  If it appears to you fine,
>> > > could you merge it?
>> > 
>> > 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?
>> 
>> 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.
> Fair enough.
>
>> 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>
> 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.
>
>> However, if a table containing what these utilities do seems
>> appropriated, here the description from the Debian package
>> ’libarchive-tools’:
>> 
>> --8<---------------cut here---------------start------------->8---
>> The bsdtar program is the default system 'tar' program used on
>> FreeBSD. bsdtar uses the libarchive library as a backend which does
>> all of the work for reading and writing archives in various formats.
>> 
>> The bsdcpio program is the default system 'cpio' program used on
>> FreeBSD. bsdcpio uses the libarchive library as a backend which does
>> all of the work for reading and writing archives in various formats
>> 
>> The bsdcat program reads archived data from files or from its
>> standard input and uses the libarchive library to decompresses it to
>> its standard output. It may be used for viewing the contents of
>> archives or for passing it to other tools for further processing.
>> --8<---------------cut here---------------end--------------->8---
> 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

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

[bug#52109] Mention bsdcat, bsdcpio and bsdtar in description of libarchive

[zimoun]

Hi Liliana,

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

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

Well, I think the addition of a ’bin’ outputs would be the most
suitable, even if it is a core-updates change.

> 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

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

[bug#52109] Mention bsdcat, bsdcpio and bsdtar in description of libarchive

[Liliana Marie Prikler]

Am Montag, dem 23.01.2023 um 08:45 +0100 schrieb zimoun:
> Hi Liliana,
> 
> On Sun, 22 Jan 2023 at 18:44, Liliana Marie Prikler
> <liliana.prikler@gmail.com> wrote:
> 
> > 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.
> 
> Well, I think the addition of a ’bin’ outputs would be the most
> suitable, even if it is a core-updates change.
> 
> > 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
> 
> 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?
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