Spec URL: http://sundaram.fedorapeople.org/unrar.spec SRPM URL: http://sundaram.fedorapeople.org/unrar-0.0.1-1.20070515cvs.src.rpm Description: unrar is a free software RAR archive extractor. It uses the GPL'd UniquE RAR Library by Christian Scheurer and Johannes Winkelmann. unrar is a simple command-line front-end to this library, and can list and extract RAR archives.
Scratch build http://koji.fedoraproject.org/koji/taskinfo?taskID=183984
Weird; this package builds fine in mock but when I tried to build it on a rawhide machine outside of mock it failed: + /usr/lib/rpm/find-debuginfo.sh /tmp/unrar-0.0.1 extracting debug info from /var/tmp/unrar-0.0.1-1.20070515cvs.fc8-root-tibbs/usr/bin/unrar Only dest dir longer than base dir not supported error: Bad exit status from /var/tmp/rpm-tmp.28856 (%install) I've no idea what's up there; perhaps something's gone wrong with that machine. It builds OK on an FC5 machine I have around. You should beware that livna already has a package named "unrar", and I would urge you to at least let them know that you plan to add a package with the same name. It has a much higher version number so I expect there to be some level of user confusion. It seems to me that because bundling libraries is generally a bad thing, it would make more sense if the "UniquE RAR Library" were packaged separately and this package just depended on it. Perhaps that will happen in the future. * source files match upstream: 08426f7eafda45cdea6e3928c232c3fc9f81fb5c754996acdfac9d0ece2bf439 unrar-free_0.0.1+cvs20070515.orig.tar.gz * package meets naming and versioning guidelines. * specfile is properly named, is cleanly written and uses macros consistently. * summary is OK. * description is OK. * dist tag is present. * build root is OK. * license field matches the actual license. * license is open source-compatible. * license text included in package. * latest version is being packaged. * BuildRequires are proper (none) * compiler flags are appropriate. * %clean is present. * package builds in mock (development, x86_64). * package installs properly * debuginfo package looks complete. * rpmlint is silent. * final provides and requires are sane. * %check is not present; no test suite upstream. I tried it on a handy rar file and it seems to work fine. * no shared libraries are added to the regular linker search paths. * owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * no scriptlets present. * code, not content. * documentation is small, so no -docs subpackage is necessary. * %docs are not necessary for the proper functioning of the package. * no headers. * no pkgconfig files. * no static libraries. * no libtool .la files. APPROVED
New Package CVS Request ======================= Package Name: unrar Short Description: 3D Game of Foo Owners: sundaram Branches: F-7 EL-4 EL-5 InitialCC: Cvsextras Commits: yes
Correction in description New Package CVS Request ======================= Package Name: unrar Short Description: RAR archive extractor Owners: sundaram Branches: F-7 EL-4 EL-5 InitialCC: Cvsextras Commits: yes
> BuildRoot: %%{_tmppath}/... Should be BuildRoot: %{_tmppath}/...
Ah. Great spot. I have fixed that now. http://sundaram.fedorapeople.org/unrar.spec http://sundaram.fedorapeople.org/unrar-0.0.1-2.20070515cvs.src.rpm
Wow, how'd I miss that one? Hmm, script checks that the components are there but doesn't care about syntactic bits like that. I guess I need to hack more.
(In reply to comment #2) [...] > You should beware that livna already has a package named "unrar", and I would > urge you to at least let them know that you plan to add a package with the same > name. It has a much higher version number so I expect there to be some level of > user confusion. There will be even more confusion when the users find out that this unrar cannot unpack their rar archives, because the majority of what's out there is produced by rar-3.x, which this library cannot handle (it only supports compression algorithms of rar-2.9x or older).
This package opens all the RAR files that I could find so it is certainly useful for me. The spec is based on Ville's and on this package has been submitted here based on his request. Feel free to engage in a debate on list about the pros/cons of this software elsewhere and let's focus on packaging here.
(In reply to comment #2) > You should beware that livna already has a package named "unrar", and I would > urge you to at least let them know that you plan to add a package with the same > name. It has a much higher version number so I expect there to be some level of > user confusion. For this issue, how do you think about making this (Fedora's) new unrar have "Epoch 1"?
(In reply to comment #10) > (In reply to comment #2) > > > You should beware that livna already has a package named "unrar", and I would > > urge you to at least let them know that you plan to add a package with the same > > name. It has a much higher version number so I expect there to be some level of > > user confusion. > > For this issue, how do you think about making this (Fedora's) new > unrar have "Epoch 1"? Using an Epoch seems like a big kludge. :| If we can get the Livna and Fedora maintainers cooperating about naming/versioning, we can skip the Epoch necessity altogether. Not sure how feasible such cooperation would be though, from a technical standpoint...
In the rare cases where I've needed unrar, this particular version of it has done the job just fine. I don't know what version of rar have those files been compressed with though. But anyway, I don't think Epoch would be a good solution as this one is allegedly an inferior implementation in functionality compared to the non-free one; just leave things as is. That way people who need the non-free unrar and use repositories that ship it can just upgrade to it and this package won't stand in the way.
Other possibilities are to simply rename this package to "unrar-free" or to coordinate a rename of the livna package to "unrar-nonfree" with the Fedora release and simply not push this package to F7.
Sure, but I can't think of a reason offhand why someone would want both this and the nonfree unrar installed, nor what else the -free and -nonfree suffixes would be useful for.
Well, the utility seems obvious to me: solves the issue of having a package in livna with the same name as a package in Fedora.
Maybe it's just me, but I don't think that's a problem that really needs to be solved in this particular case. And it's not even clear that an unrar package will be shipped in Livna after this is in Fedora (it's unmaintained there already). But if Livna drops it, Epoch bump would be appropriate here. Just my .02€, feel free to proceed as you wish.
Perhaps it's worth pinging the fedora-devel and/or livna freeworld lists before importing this to see if anyone has any better solutions to co-existance of the two packages. Given comment #16 it sounds like it might not be in livna too much longer anyhow...
Uh, looking at the code in the SRPM, this appears to be the same code used in clamav. The legal status of that code is not clear to me. (In fact, I considered bringing this up with respect to clamav, but seeing the same code used in another package makes this all the more urgent.) The file headers say: "This code is based on the work of Alexander L. Roshal". But then isn't it a derived work of the original unrar sources? If it is, it's illegal to distribute this under the GPL as they're doing because the original unrar license is non-Free and not GPL-compatible. This (libclamav unrar) code also has a history of sharing the security vulnerabilities of the non-Free unrar, which also sounds unlikely for a truely independent implementation. See for example http://www.securityfocus.com/archive/1/473373/100/0/threaded .
From http://www.unrarlib.org/faq.html Do you know that the license for the unrar sources from RARLab is not compatible with the GNU Public license? Yes, this is true. But we have the permission from Eugene Roshal to release unrarlib 0.4.0 under GPL and unrarlib-license. Note: this doen't mean that RAR is free now or you can use the unrar source from RARlabs under GPL. You are just allowed to use UniquE RAR File Library version 0.4.0 (unrarlib 0.4.0) under GPL. Does that answer you?
But this applies to the old RAR v2 only unrarlib. The RAR v3 decompression code has been added later by the clamav people, and it's that which I'm concerned about.
More details would be helpful. Which files implement RARv3 decompression in unrar that was added by Clamav developers? If this affects Clamav too, you file a bug report and mark that and this review against Fedora Legal or post to fedora-legal-list with the details. CC'ing Tom Callaway.
All the files in http://cvs.gna.org/cvsweb/unrar/src/?cvsroot=unrar which have newly appeared with the "merge things from unrarlib sourceforge svn, the code comes from libclamav." commit are suspicious. libclamav's version of the code is here: http://svn.clamav.net/websvn/listing.php?repname=clamav-devel&path=%2Ftrunk%2Flibclamav%2Funrar%2F&rev=0&sc=0 First version: http://svn.clamav.net/websvn/listing.php?repname=clamav-devel&path=%2Ftrunk%2Fclamav-devel%2Flibclamav%2F&rev=1471&sc=1
What puzzles me most is this : Q: There is no way to create a RAR archive with the URARFileLib. When will you add a "create archive" function? A: Probably never. The license of the free unrar source code prohibits making a tool that can create RAR compatible archives. This restriction would be clearly incompatible with the GPL, so if the source code was released under "the GNU GPL with the restriction to not use the code to reverse engineer the process of creating rar archives", then we clearly have a problem.
I don't see such a restriction listed out in the actual source code which is under plain GPL2 or later license. The copyright license in the source package has a higher legal value over any website.
I spoke via email to Eugene Roshal about this issue. He was unaware that clamav had used derived code from their implementation in clamav, under the GPL license, and stated that he did not grant them permission to do so. He said that the only way he was willing for such code to be used was with a clause like the following: "The unRAR sources cannot be used to re-create the RAR compression algorithm, which is proprietary. Distribution of modified unRAR sources in separate form or as a part of other software is permitted, provided that it is clearly stated in the documentation and source comments that the code may not be used to develop a RAR (WinRAR) compatible archiver." Unfortunately, such a restriction conflicts directly with the GPL, and is a showstopper. This code cannot go into Fedora as is. All RAR v3.x support would need to be stripped out, before it could be considered. Given that most RAR files are RAR v3, that severely limits the usefulness of this application. In addition, we will need to strip the RAR v3 code out of clamav.
Have you contacted ClamAV upstream about this already? I'm sure Sourcefire, the company which now provides the infrastructure for ClamAV and bought most of the copyrights, will want to know they're distributing illegal code...
I just sent them an email (I have a friend who's one of the clamav developers), and I'm about to poke the clamav maintainer.
Bug opened against clamav: 334371
Thanks spot for looking into this. Closing this review request.
Hmm, couldn't we atleast have a version in Fedora for handling rar v2 files, because AFAIK unless some special options are checked, rar v3 still produces files compatible with rar v2, iow it never uses the new rar v3 algorithm's unless explicitly told too. I understand that the clamav rar implementation is a no go, but what about libunrar, if they got permission to release things unfer the GPLv2, then that should be in the clears, right? Then an unrar based of that without any of the clamav "fixes" should be fine too, right? Then we can also fix the name conflict be calling this unrarv2 both the package and the binary, and teach things which want to use it like mc to first try unrar and only if that is not present try unrarv2
Yep. You could do that.
We have to patch every program that calls unrar which includes many graphical archive managers like file roller and ark? That doesn't sound like a good idea to me. If the stripped down version of unrar can still open majority of the rar files, I can continue with importing and maintaining this which I assume is basically sticking with the same version but we need to find a way to have both the free and the non-free versions co-exist without patching all the other programs.
This has been removed from the cvs repository for now. If you do come up with a plan to include only OSS pieces in Fedora, please make a new cvsadmin request to re-add the package. Rahul, could you add something to http://fedoraproject.org/wiki/ForbiddenItems to explain the situation with this library?
> If the stripped down version of unrar can still open majority of the rar > files The problem is, it can't. :-( The only reason this version of unrar can decompress most RAR files is that very RARv3 code which has the licensing issues. Most RAR archives these days are v3.
(In reply to comment #34) > > If the stripped down version of unrar can still open majority of the rar > > files > > The problem is, it can't. :-( > > The only reason this version of unrar can decompress most RAR files is that > very RARv3 code which has the licensing issues. Most RAR archives these days > are v3. Hmm, Has anyone actually tested this?
Flipping this review to - so it doesn't show up in the report.
FYI: %changelog entry from Enrico's clamav commit in CVS yesterday: - ship original sources again; unrar is now licensed correctly (no more stolen code put under GPL) [...] ...so maybe this package could be resurrected after merging the codebase with the clamav sources?
No. The unrar license is itself not-permissable for Fedora, and we cannot even ship the source code, due to clause 6 of the unrar license: "If you don't agree with terms of the license you must remove UnRAR files from your storage devices and cease to use the utility." I would really prefer that upstream clamav pull out libclamunrar*, as there is no possible universe in which it can be enabled and legally redistributed, however, in the interim, we need to remove it ourselves. Enrico, can you do this, or would you like me to handle it?
Here is Debian's discussion on the same topic http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=312552 It's not clear if the new v3 support mentioned near the bottom is something different than the encumbered implementation. The Debian version 1:0.0.1+cvs20071127-1 lists the following in the changelog "remove RARv3 code from libclamav due to unclear license and patent issues" so is it now clean again or is there some other issue? RE comment #32, Debian has switched to using /etc/alternatives for unrar, I assume fedora could do similar? If this enough to make it ok for Fedora as well or is there still something I'm missing?
> It's not clear if the new v3 support mentioned near the bottom is > something different than the encumbered implementation. Oops, meant to trim that part, the v3 support mentioned _is_ from libclamav and is the stuff that was removed in the version mentioned. Sorry for the confusion.
Almost all of the files that are available in the wild is compressed using the new v3 format which is not under a free and open software license. The free portions are unfortunately pretty much useless as a result and would probably just serve to cause confusion. If anybody else disagrees, they are free to submit the non-encumbered portions as a package to Fedora but I won't likely be taking that effort myself.