This is a problem I noticed with GHC: the package files created by quickpkg and by "emerge -b" are not identical. This seem to lie in that "emerge -b" prefixes the path with a "./". It may not look that serious, but combined with the way GHC is packaged it creates problems: The file ghc-bin-6.10.4-amd64.tbz2 is a binary tarball generated from another system to bootstrap ghc while building. When generated with quickpkg it works like it should (at least here) but if you generate it with "emerge -b" it always (like in the output below) thinks that the mtime has been changed. # ebuild /var/overlays/mine/dev-lang/ghc/ghc-6.10.4-r1.ebuild unpack >>> Existing ${T}/environment for 'ghc-6.10.4-r1' will be sourced. Run >>> 'clean' to start with a fresh environment. * ghc-6.10.4-src.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * ghc-bin-6.10.4-amd64.tbz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking ghc-6.10.4-src.tar.bz2 ;-) ... [ ok ] * checking ghc-bin-6.10.4-amd64.tbz2 ;-) ... [ ok ] * CPV: dev-lang/ghc-6.10.4-r1 * REPO: Mine! * USE: amd64 bash-completion elibc_glibc kernel_linux multilib test userland_GNU >>> Checking ghc-6.10.4-src.tar.bz2's mtime... >>> ghc-6.10.4-src.tar.bz2 has been updated; recreating WORKDIR... >>> Unpacking source... >>> Unpacking ghc-6.10.4-src.tar.bz2 to /var/tmp/portage/dev-lang/ghc-6.10.4-r1/work >>> Unpacking ghc-bin-6.10.4-amd64.tbz2 to /var/tmp/portage/dev-lang/ghc-6.10.4-r1/work bzip2: /var/tmp/portage/dev-lang/ghc-6.10.4-r1/distdir/ghc-bin-6.10.4-amd64.tbz2: trailing garbage after EOF ignored * Applying ghc-6.10.4-autoconf.patch ... [ ok ] * Applying ghc-6.10.4-libm-detection.patch ... [ ok ] * Running eautoreconf in '/var/tmp/portage/dev-lang/ghc-6.10.4-r1/work/ghc-6.10.4' ... * Running autoconf ... [ ok ] * Running autoheader ... [ ok ] >>> Source unpacked in /var/tmp/portage/dev-lang/ghc-6.10.4-r1/work So as I see it we have two problems here: 1. emerge -b creates archives with a "./" in the path, not only looking ugly, but different from quickpkg 2. emerge/ebuild fails to handle mtimes correctly when the packages contains a "./" in its path. This leads to currently with all files only from portage there is no possibility to with the help of ebuild debug the ghc ebuild, as if you try to change something in workdir, then the command ebuild erases it and recreates the workdir even when it should not. Both quickpkg and "emerge -b" creates packages with 8 blocks of trailing data, the only difference I could find was that "./" but if it can be something else, please advice.
This thing about ./ in the path seems like it might be a red herring. (In reply to comment #0) > >>> Checking ghc-6.10.4-src.tar.bz2's mtime... > >>> ghc-6.10.4-src.tar.bz2 has been updated; recreating WORKDIR... > >>> Unpacking source... Is this the mtime thing you're talking about? The portage code there is a little bit dumb, but there is a reason for it. I don't understand why you are trying to re-use the existing content of WORKDIR instead of doing a fresh unpack. Can you explain?
(In reply to comment #1) > This thing about ./ in the path seems like it might be a red herring. > Yeah, I think so to > Is this the mtime thing you're talking about? The portage code there is a > little bit dumb, but there is a reason for it. I may understand it, but still I do think it is nice if portage does not break with files it self has created > I don't understand why you are > trying to re-use the existing content of WORKDIR instead of doing a fresh > unpack. Can you explain? > GHC has many problem on hardened, and I am trying to figure out why some stuff does not work like it should. I try to do this by issuing "ebuild compile", see what breaks, maybe make a small change to see how it reacts and then "ebuild compile" again. If workdir then is preserved you can pretty easily see if it broke more or actually is something to try make a patch out of. However if it behaves like for GHC (mind only with packages generated by "emerge -b", not by quickpkg) then you actually have to make the ebuild make those small changes every time, which is somewhat timeconsuming if you only are poking around trying to figure out why -nopie was not added in a command where it should be.
*** This bug has been marked as a duplicate of bug 332217 ***
