#82 Built in RAR support using free software

SVN
open
nobody
None
5
2015-04-14
2014-01-13
Alan Horkan
No

I've used MComix on a few distributions and it does not support RAR out of the box, which at times is more of a hassle than you might think. (There are plenty of distributions that do not want to offer the binary unrar, and others make it a bit of a hassle to get rar working.)

Of the free software alternatives the best seems to be Unarchiver, which offers command line versions for Linux (even packages for Ubuntu)
http://unarchiver.c3.cx/commandline
the code is LGPL
http://code.google.com/p/theunarchiver/

It would be great if you could change MComix so that it could extract RAR files out of the box. Presumably on Ubuntu this would take a bit of glue code to get the right command line incantation and a dependency check to make sure theunarchiver was installed.

Discussion

  • Oddegamra

    Oddegamra - 2014-01-13

    How about 7zip? In fact, MComix should already fall back to 7z if it is available.

    I keep RAR around because unpacking RAR archives using libunrar, as opposed to spawning a CLI tool, is faster by a good margin (and by that I mean way faster) and supports native unicode filenames for archive files.

     
  • Alan Horkan

    Alan Horkan - 2014-04-27

    As a user I feel a bit stupid and surprised to install a comic viewer, and to find out I have to do more things to get it to open CBR files which unfortunately nearly everyone uses.

    Ubuntu include p7zip but ...
    https://apps.ubuntu.com/cat/applications/p7zip-full/
    "RAR (only if non-free p7zip-rar package is installed)"

    ... that means we're back to the same crappy situation for users, of having to jump through several extra steps (enable non-free, install additional packages), to get what I think most users consider a basic feature of a comic viewer, that it can open the most common type of comic archives.

    and unrar-free seems like it just doesn't support enough typs of RAR file to be useful
    https://apps.ubuntu.com/cat/applications/unrar-free/
    (haven't tested it, but it says it does not support RAR3 which is roughly 2002 onwards)

    While I admire their strict stance on software freedom, it creates a really sucky experience for users. You may as well close this request, there isn't much you can do about the larger problem of proprietary formats that just wont go away. I'll just have to remember to enable non-free and install RAR first things when I install a linux distrubtion.

     
  • FeRD

    FeRD - 2014-05-13

    The Unarchiver (or its command-line unar tool, which Fedora also packages) does show some promise, since it's both free and apparently featureful/compatible enough that it should be sufficient to meet all the needs of most users.

    Unfortunately, as it began life as Mac code, unar is writen in Objective-C, and making it generally useful on other platforms may be a chore. Ideally, if it could be rolled into a libunar.so shared library, that might serve as a replacement for libunrar.so. The GCode page claims "Version 2.0 uses an archive-handling library built largely from scratch in Objective-C", but here we are at version 3.9 and there's no Linux-side libunar in sight.

    (The Mac-world-y, Obective-C-ness also makes it weird in other ways. Like, the command line options for unar all feel weird and uncomfortable. I can't fathom why it wouldn't just be commandline-compatible with unrar, because that would be soooo much simpler and more useful!)

    ...Your original request got me curious about how my system is handling RAR files, because Fedora's mComix package is distributed by the Project, while libunrar is distributed by RPMFusion (our "non-free" package collection maintainers). That means Fedora's mcomix can't possibly be linked with libunrar.

    After tracing the process, I discovered that it is in fact falling back to commandline unrar. (And in an odd-looking way that causes a flurry of threads to be spawned, literally several dozen, just in moving from one .CBR file to another! Not sure what's up with all that, but I think it's "unrar being unrar", so "whatever".)

    Given that, and the fact that an external command is already being run to do the archiving, I agree that it would be a major win if mComix also supported unar as a RAR tool. If that were the case, Fedora could package mComix to depend on unar, and RAR support would be pulled in so it worked out-of-the-box for us, as well.

    Please do keep this request open, as unar support seems extremely desirable in mComix if someone were to invest the time.

     
  • Oddegamra

    Oddegamra - 2014-05-13

    MComix does not link statically to libunrar.so, but dynamically using Python's ctype module (the library is loaded at runtime if available).

    Extraction using a command line tool is generally slow in MComix because each file is extracted using its own process. This was done due to the problem that most archives do not have a well-defined file name encoding, so MComix cannot always know how the resulting file names (when extracting the whole archive at once to a given location) are encoded. Thus, each file is extracted to STDOUT and written to a temporary file by MComix instead.

    Of course, that means that each process will have to open the file, seek to the correct position, extract parts of the archive that must be discarded and so forth.

     
    • FeRD

      FeRD - 2014-05-13

      MComix does not link statically to libunrar.so, but dynamically using Python's ctype module (the library is loaded at runtime if available).

      Yeah, I was thinking of compiled code, where the linking (which is actually still dynamic, it's impossible to statically link to a .so) needs to be done at compile time, preventing free distribution packages from being able to link with non-free shared libraries.

      But because it's Python, you can dynamically load /usr/lib[64]/libunrar.so at runtime despite the distribution's packaging having no knowledge of its existence. Sweet.

      Turns out, I'd simply neglected to install libunrar. (That's the flip side of that "distro package has no knowledge of it" problem: it's impossible for the mComix package to pull in libunrar as a dependency.) So, because I did have commandline unrar installed, mComix fell back to that instead. Once I installed libunrar, mComix picked it right up as expected.

      But performance concerns aside, both unrar and libunrar suffer from the same problem: They're non-free. Whereas, like Alan pointed out, if mComix had unar support (commandline for now, unless someone manages to wrap it into a library), it would support RAR / CBR files out-of-the-box on free software distributions. That'd be a major benefit for Linux newbies who aren't yet up to speed on things like non-free PPAs or RPMFusion, and in environments where policy or philosophy prevent the installation of non-free tools like both unrar and libunrar.

      Plus, aside from translating the command-line options, I can't imagine there'd be much more to adding unar support than a cut-and-paste from the existing unrar support, right?

      (Please note, I am not in any way saying, "You should do this, it's simple!" — I would never be so presumptuous! I'm just pointing out the tangible benefits from not a lot of work, which makes it seem worth someone's time. Heck, if I get motivated perhaps I'll submit the patches myself.)

       
  • Hanno Böck

    Hanno Böck - 2015-04-13

    Just fyi, libarchive supports rar files (and a ton of other file formats), is free and a lot less kludgy than unarchiver (which requires objective C and a few uncommon dependencies).

    So I think using libarchive would be the way to go.

     
  • FeRD

    FeRD - 2015-04-14

    Unfortunately, AFAICT libarchive still doesn't have support for reading encrypted/password-protected RAR archives, which is a feature of the current MComix rarfile code. So, it would be a regression to switch to libarchive.

    (Also, from a quick look at python-libarchive, which is a separate project from libarchive itself, it seems rather barebones and limited at this time.)

     

Log in to post a comment.