| Summary: | lha-114i-r6 seems to reject the q argument during unpack (in portage-2.1.3_rc7) | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Mike Auty (RETIRED) <ikelos> |
| Component: | Core - External Interaction | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | brebs, john_r_graham |
| Priority: | High | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 181949, 187293 | ||
See bug #159100, which has an ebuild for Debian's lha. the lha command used to work (it did when i added it), so lha is broken here *** This bug has been marked as a duplicate of bug 159100 *** This does not appear to be a duplicate of bug #159100. According to the built-in help for lha, the q option takes an optional parameter, which seems to be a "required" parameter if more options follow. You can see it right in the output from post #1. The command line that works is: lha xq2f some_file_name or even lha xfq some_file_name Perhaps the command line parser needs to be made smarter, but this is definitely not related to the "unable to extract quake files" bug. Should this bug be reopened as a "fix the command line parser" bug? Or, should it just left alone since it actually appears to be behaving as designed? - John I've changed it to xfq. I'm not certain that will work as expected because the -f option will expect the filename, rather than a q immediately after it... I'd either explicitly specify a quiet level (like xq2f), or split the arguments as in comment 1: lha x -q -f "${srcdir}/${x}" || die "$myfail" xfq works because according to --help f really means "force (over write at extract)". I chose xfq in hopes that it wouldn't trigger any backward compatibility problems with older versions of lha that apparently accepted xqf (probably not an issue since we only have one version in the tree now). You're entirely right, I'm sorry. Serves me right for relying on my own memory! I do apologize... 5:( This has been released in 2.1.3_rc9. (In reply to comment #2) > the lha command used to work (it did when i added it), so lha is broken here > > *** This bug has been marked as a duplicate of bug 159100 *** > SpanKY's right, by the way. Between lha-114i-r5 and lha-114i-r6, the command line parser became more strict. It *did* used to work. - John |
I was just writing a little ebuild for an ancient tool that's packed up as a .lzh. I installed lha-114i-r6 and tried letting portage's unpack function handle it. I was amazed that it tried, but it produced: >>> Unpacking msbklin.lzh to /var/tmp/portage/app-arch/ntbkup-1.07/work lha: invalid option -- q usage: lha [-]<commands>[<options>] [-<options> ...] archive_file [file...] commands: [axelvudmcpt] options: [q[012]vnfto[567]dizg012e[w=<dir>|x=<pattern>]] long options: --system-kanji-code={euc,sjis,utf8,cap} --archive-kanji-code={euc,sjis,utf8,cap} --extract-broken-archive --help --version * * ERROR: app-arch/ntbkup-1.07 failed. * Call stack: * ebuild.sh, line 1647: Called dyn_unpack * ebuild.sh, line 768: Called qa_call 'src_unpack' * ebuild.sh, line 44: Called src_unpack * ebuild.sh, line 654: Called unpack 'msbklin.lzh' * ebuild.sh, line 461: Called die * * failure unpacking msbklin.lzh * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/app-arch/ntbkup-1.07/temp/build.log'. * This ebuild is from an overlay: '/usr/local/overlays/shc-tools/' * which I then tracked down to the line in /usr/lib/portage/bin/ebuild.sh: lha xqf "${srcdir}/${x}" || die "$myfail" I tried several different variations, and it seems the q and f don't go so well right next to each other. I ended up with: lha x -q -f "${srcdir}/${x}" || die "$myfail" which seems to work fine.