The unpack() function for ebuilds does not take into account the actual file type when determining if it can unpack one of its parameters. I have a binary blob ebuild I'm writing for in house solution and upstream will not rename one of their tar files away from .pdb extension. Unfortunately, unpack silly.pdb, even after it has been properly fetched via SRC_URI, fails. $ file /usr/portage/distfiles/us-prod-profile-linux.pdb /usr/portage/distfiles/us-prod-profile-linux.pdb: POSIX tar archive (GNU) unpack "us-prod-profile-linux.pdb" yields: unpack us-prod-profile-linux.pdb: file format not recognized. Ignoring. I would request that unpack be more lenient for its unpacking criteria. Thanks! Reproducible: Always Expected Results: unpack can handle anything which `tar` can
Created attachment 116508 [details] emerge --info
How about using something similar to this in the ebuild? src_unpack() { myA=${A%.*}.tar mv ${DISTDIR}/${A} ${DISTDIR}/${myA} unpack ${myA} }
This would cause refetch of the .pdb every time.
Then use cp, I was just pointing to the fact that you can manipulate the file before unpack.
Yep, that is the work around I'm using now. I beleive that unpack can, and should, be smarter about prematurely bailing out of an unpack operation. Running `file` on the parameter would quickly show that we're dealing with a GNU archive and are eligible for processing from unpack.
i dont see much value in the over head needed in order to properly detect a file by ignoring its suffix ... just symlink it: ln -s ${DISTDIR}/${A} ${A}.tar unpack ./${A}.tar
*** Bug 210878 has been marked as a duplicate of this bug. ***
