On Tue, Mar 04, 2014 at 11:13:54AM -0500, Cole Robinson wrote: > On 03/04/2014 11:02 AM, Cole Robinson wrote: > > On 03/04/2014 04:06 AM, Martin Kletzander wrote: > >> On Tue, Mar 04, 2014 at 04:16:58PM +0800, Chen Hanxiao wrote: > >>> Commit 0b4a72fd77f74e5a9f6885179febe601156df617 > >>> needs unar command to do some tests. > >>> > >>> But if we haven't installed it, the error message > >>> told us nothing valuable as: > >>> "OSError: [Errno 2] No such file or directory" > >>> > >>> This patch will impove the error message. > >>> > >>> Signed-off-by: Chen Hanxiao <chenhanxiao@xxxxxxxxxxxxxx> > >>> --- > >> > >> I got to the bottom of this when I first saw the error and after some > >> time installed it. But since you're posting this question, shouldn't > >> we put unar into .spec.in file and check for it while running > >> setup.py? > >> > > > > Were you guys hitting this from the test suite? > > Yes, exactly. > >> Or even better, can't we use something else than unar since on source > >> distributions this requires objective C compiler and some other not > >> very usual packages. It seems a little bit cumbersome for some users; > >> and yes, I understand it's the minimum, but if there's an easier way > >> than we may as well be nice. > >> > > > > Hmm, didn't realize unar wasn't just a plain C app. That makes adding an > > explicit dep kind of annoying. > > I don't know how common it is, It just suprised me as a choice. > > Since it's only used as a convenience functionality of unarchiving a tar.gz or > > zip or xz, we can just fail if unar isn't available and tell the user to > > extract the directory themselves, and then point virt-convert at the > > directory. For the test suite, we can just duplicate the unar check and skip > > the tests if it's not available. > > The more thorough alternative is to call out to xz, tar, bzip2 etc as dictated > by the file extension... but that's a decent chunk of work and IMO isn't worth > the effort for a tool with such few users. > Or recursively call something like '7z x filename' while the output is one compressed file (to cover .gz, tar.gz, .xz, etc.). p7zip is LGPL-2.1 with unRAR restrictions in case it's compiled with unrar option. But since we wouldn't be linking with it that isn't something we should be worried about, I think. That would be way easier to code and wouldn't require so many tools. OTOH it would be dependent on one tool (for any compressed input) and that might be taken as a disadvantage as well (as with unar). Just my 2¢, I'm fine with any outcome. Martin > - Cole
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
