Created attachment 305843 [details, diff] replace ar in unpack_deb 1.) The attached patch will replace the call to ar in unpack_deb with bash and coreutils calls (bug #384147#c19). This will help unpacker.eclass on AIX - a version of the patch was tested by haubi before. 2.) The unpack_banner is sometimes misleading. "unpacker path/to/file.gz" will unpack file.gz to path/to and not to PWD. So either we fix the message or the target directory.
I think your patch is reversed there.
(In reply to comment #1) > I think your patch is reversed there. Yes, it is reverted. But let's discuss point 2, first!
(In reply to comment #2) > Yes, it is reverted. But let's discuss point 2, first! Not much to discuss. I think changing it to unpack in the current directory is the way to go and matches the behavior of unpack.
Comment on attachment 305843 [details, diff] replace ar in unpack_deb i find it hard to say the proposed replacement is better. if you want to restrict the code to only run for certain targets, then that'd be fine. as for your (2), `unpacker` is supposed to act like `unpack`, so it should extract to $PWD.
(In reply to comment #4) > Comment on attachment 305843 [details, diff] [details, diff] > replace ar in unpack_deb > > i find it hard to say the proposed replacement is better. if you want to > restrict the code to only run for certain targets, then that'd be fine. No problem, we can surround it by add [[ ${EPREFIX} ]]. @haubi: Would that be sufficient? > > as for your (2), `unpacker` is supposed to act like `unpack`, so it should > extract to $PWD. Good, I will create a patch for that.
Created attachment 306377 [details, diff] unpack to PWD
Comment on attachment 306377 [details, diff] unpack to PWD thanks, committed http://sources.gentoo.org/eclass/unpacker.eclass?r1=1.5&r2=1.6
Created attachment 308253 [details, diff] replace ar in unpack_deb Put usage of ar replacement inside EPREFIX conditional.
Comment on attachment 308253 [details, diff] replace ar in unpack_deb there should be a space after the comment markers ("#") use ${f} and ${size} why change from `unpack` to `unpacker` ?
Created attachment 308359 [details, diff] replace ar in unpack_deb (In reply to comment #9) > there should be a space after the comment markers ("#") Fixed. > > use ${f} and ${size} Fixed & fixed. > > why change from `unpack` to `unpacker` ? Why not? It makes it more self-contained and unpacker fails back to unpack anyway.
(In reply to comment #10) because unpacker handles things like .xz files in any EAPI which `unpack` does not. if you have no technical reason for using `unpack`, then don't. in fact, this was one of the entire reasons for unpacker.eclass in the first place.
(In reply to comment #11) > (In reply to comment #10) > > because unpacker handles things like .xz files in any EAPI which `unpack` > does not. if you have no technical reason for using `unpack`, then don't. > in fact, this was one of the entire reasons for unpacker.eclass in the first > place. I don't understand your comment. I changed from unpack to unpacker in unpack_deb.
Created attachment 308845 [details, diff] add support to unpack rpm
(In reply to comment #12) true, i confused myself. committed now. http://sources.gentoo.org/eclass/unpacker.eclass?r1=1.6&r2=1.7 (In reply to comment #13) i don't want this bug to turn into a dumping ground for random improvements. one issue per bug after this please.
(In reply to comment #14) > (In reply to comment #12) > > true, i confused myself. committed now. > http://sources.gentoo.org/eclass/unpacker.eclass?r1=1.6&r2=1.7 > > (In reply to comment #13) > > i don't want this bug to turn into a dumping ground for random improvements. > one issue per bug after this please. Ok, I promise this will be the last one ;-) 1.) I don't like the part of the rpm patch where everything is unpacked from a src rpm as newer rpm may contain other format than *.tar.{gz,bz2} *.t{gz,bz2} *.zip *.ZIP. 2.) And rpm_spec_epatch from rpm.eclass is also used in two ebuilds (gdb and pax).
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #12) > 2.) And rpm_spec_epatch from rpm.eclass is also used in two ebuilds (gdb and > pax). That should go into epatch.eclass.
(In reply to comment #15) the trouble is that an rpm can include pretty much anything, so it's hard to say what should/shouldn't be unpacked
(In reply to comment #17) > (In reply to comment #15) > > the trouble is that an rpm can include pretty much anything, so it's hard to > say what should/shouldn't be unpacked Agreed, so I guess we should just unpack the rpm and leave the rest to the ebuild writer, that is also more clean and predictable. (In reply to comment #15) > 2.) And rpm_spec_epatch from rpm.eclass is also used in two ebuilds (gdb and > pax). Newer version of gdb don't use rpm_spec_epatch anymore and pax could be pulled from debian instead.
Let's not merge this and leave rpm.eclass alone.
