Issue description
Nixpkgs ships with unrar. Unrar is not free software because the unrar license forbids reverse engineering of the rar compression algorithm.
Until recently, no other software was able to uncompress RAR v2.9+ formats. (Edit: 7z can uncompress RAR files.)
Since May 2016, TheUnarchiver supports RAR v5 files [1]. So now the command-line tool unar can be used instead of unrar.
Other distros such as Debian already ship unar [2].
[1] http://unarchiver.c3.cx/formats
[2] https://packages.debian.org/jessie/unar
vandenoever
All 15 comments
But 7z has the unrar capability already.
Anyway, a good acquisition to nixpkgs tree.
AndersonTorres
on 12 Jul 2016
I did not know that 7z supports unpacking of RAR 2/3/4/5. That is great news.
7-Zip 9.20 supports RAR 2/3/4 formats only and doesn't support RAR5 archives. But latest versions of 7-Zip supports RAR5 archives.
http://www.7-zip.org/faq.html
So the unrar dependency can probably go from ark and callibre.
vandenoever
on 12 Jul 2016
Is a good idea of add TheUnarchiver, but also bad idea remove unrar completely. Let folks to have a choice.
avnik
on 13 Jul 2016
Ark does not support using 7z for rar, but it does support using unar instead of unrar [1]. That's a good reason for packaging unar.
vandenoever
on 13 Jul 2016
7z's rar support is based on unrar, so it does suffer from the same licensing problems. I'd be very suspicious about any RAR-unpacking tool claiming to have a completely free license, but reading Debian's copyright file is enough to me.
vcunat
on 14 Jul 2016
@matthewbauer has been working towards proper support for objective-c Foundation libraries and gnustep-make making my PR redundant and my WIP package likely obsolete.
I've taken the first step into packaging this in https://github.com/NixOS/nixpkgs/pull/16981.~~
Note however that what follows is quite hard for me to do without OSX to test things out:
1, The build wants to use gcc for objective-c but that's isDarwin... I can force it with ( gcc.cc.override { langObjC = true; } ) in buildInputs or I can just use clang and edit the Makefile.
2. The real tricky part is that I need the Foundation libraries but they're currently under an os-specific path.
As it is, I won't touch this further without testing changes on both Darwin and Linux. Here's what I have so far if anyone wants to keep working on this:
{ stdenv, fetchurl, gnustep-make, unzip, clang, Foundation, libobjc }:
stdenv.mkDerivation rec {
name = "${pname}-${version}";
pname = "unar";
version = "1.10.1";
src = fetchurl {
url = "http://unarchiver.c3.cx/downloads/${pname}${version}_src.zip";
sha256 = "0aq9zlar5vzr5qxphws8dm7ax60bsfsw77f4ciwa5dq5lla715j0";
};
buildInputs = [
gnustep-make unzip clang Foundation libobjc
# ( gcc.cc.override { langObjC = true; } ) #takes forever to compile. use clang instead.
];
postPatch = ''
substituteInPlace Makefile.linux \
--replace "CC = gcc" "CC=clang" \
--replace "CXX = g++" "CXX=clang++" \
--replace "OBJCC = gcc" "OBJCC=clang" #\
#--replace "OBJCXX = g++" "OBJCXX=clang++"
'';
makefile = "Makefile.linux";
sourceRoot = "./The Unarchiver/XADMaster";
meta = with stdenv.lib; {
homepage = http://unarchiver.c3.cx/unarchiver;
description = "an archive unpacker program";
longDescription = ''
The Unarchiver is an archive unpacker program with support for the popular \
zip, RAR, 7z, tar, gzip, bzip2, LZMA, XZ, CAB, MSI, NSIS, EXE, ISO, BIN, \
and split file formats, as well as the old Stuffit, Stuffit X, DiskDouble, \
Compact Pro, Packit, cpio, compress (.Z), ARJ, ARC, PAK, ACE, ZOO, LZH, \
ADF, DMS, LZX, PowerPacker, LBR, Squeeze, Crunch, and other old formats.
'';
license = licenses.lgpl21Plus;
};
}
Make sure to cherry-pick the gnustep-make PR I submitted since gnustep-make is broken in linux without it.
Good luck :)
RamKromberg
on 15 Jul 2016
Ok so unar is now in nixpkgs. What should be the closing criteria for this issue? We can remove "unar" from release-small.nix and add "unar" and then close this issue?
matthewbauer
on 3 Apr 2017
It would be great if those various apps could also be switched (ark, calibre, ...), but I don't know where the upstreams support that.
vcunat
on 3 Apr 2017
unrar is already marked as unfree package via licenses.unfreeRedistributable and only available when the allowUnfree option is set
so i think its not sensible to go for "killing" the unrar package, per se - in particular if its not yet a switchable runtime dependency for the other tools
any tool that adds rar support by expecting a unrar will need unrar until it is enhanced to also support unar
@vcunat i don't in particular understand why unrar has to go from the small build set just because a different package that is NOT a replacement is added
RonnyPfannschmidt
on 3 Apr 2017
Can you elaborate on why it is not a replacement?
vcunat
on 3 Apr 2017
for one, the commands differ, in both name and accepted arguments/cli logic, so any tool relying on unrar as a command cant use it at all,
so a well versed user may be able to use it on the cli, but any other program expecting unrar cant
unar is strictly an alternative, not a replacement
RonnyPfannschmidt
on 3 Apr 2017
Right, I didn't mean it as a drop-in replacement and we don't use it that way AFAIK. I consider it a preferred alternative.
vcunat
on 3 Apr 2017
btw, is it intended to add clang to the small set?
RonnyPfannschmidt
on 3 Apr 2017
I don't know that (and I don't see it there).
vcunat
on 3 Apr 2017
Closing this issue (triage).
kalbasit
on 5 Aug 2019
Related issues
lverns
路
3Comments
matthiasbeyer
路
3Comments
domenkozar
路
3Comments
tomberek
路
3Comments
copumpkin
路
3Comments
Most helpful comment
Is a good idea of add TheUnarchiver, but also bad idea remove unrar completely. Let folks to have a choice.