Created attachment 412394 [details] emerge --info When building with FEATURES=keeptemp, then as expected, build logs and such are left in /var/tmp/portage after a build. But these don't seem to be cleaned up properly at the start of another build, and this causes a problem during the install phase of Haskell packages: > >>> Install http-client-tls-0.2.2 into /var/tmp/portage/dev-haskell/http-client-tls-0.2.2/image/ category dev-haskell > ./setup copy --destdir=/var/tmp/portage/dev-haskell/http-client-tls-0.2.2/image/ > Installing library in > /var/tmp/portage/dev-haskell/http-client-tls-0.2.2/image/usr/lib64/http-client-tls-0.2.2/ghc-7.10.2 > Creating package registration file: > /var/tmp/portage/dev-haskell/http-client-tls-0.2.2/temp/http-client-tls-0.2.2.conf > ghc-pkg: cannot create: /var/tmp/portage/dev-haskell/http-client-tls-0.2.2/temp/http-client-tls-0.2.2.conf.d already exists > * ERROR: dev-haskell/http-client-tls-0.2.2::haskell failed (install phase): > * Failed to initialize empty local db I looked (lightly) through the devmanual and man pages but couldn't find much about the what and when of cleaning. Should portage be cleaning this up, or is this up to eclasses? From https://archives.gentoo.org/gentoo-user/message/be12611535fb722fbdcc8d2f94fed204.
This is fixable in haskell-cabal.eclass with an "rm -f" before, # Newer cabal can generate a package conf for us: ./setup register --gen-pkg-config="${T}/${P}.conf" ghc-install-pkg "${T}/${P}.conf" but I'm also curious about when the temporary directory is supposed to be cleaned. I didn't see anything in the PMS, so we should probably assume that other package managers are free to do wacky stuff and work around this in the eclass regardless.
+Zac and dev-portage@ the question for you: > FEATURES=keeptemp > Do not delete the ${T} directory after the merge process. Does that mean when you rebuild installed package then ${T} is expected recreated afresh or ${T} is left untouched? Same question for FEATURES=keepwork and ${WORKDIR} > FEATURES=keepwork > Do not delete the ${WORKDIR} directory after the merge process. ${WORKDIR} can then be reused > since this feature disables most of the clean phase that runs prior to each build. Due to > lack of proper cleanup, this feature can interfere with normal emerge operation and therefore > it should not be left enabled for more than a short period of time. It seems that keep{temp,work} behave the same now. Should we extend the man entry about FEATURES=keeptemp to make intent clear? It's not clear what phases will be reran for FEATURES=keepwork and what environment will be restored from previous run to write a well behaving ebuild :) I'd personally vote for semantic change for both FEATURES=keep{temp,work} and make them wipe all contents when new build starts. It is safer if only thing user wants is to navigate real sources when looking at gdb traces. Current behaviour could be called FEATURES=reuse{temp,work} to stress it's evil nature:) [back to haskell-cabal.eclass] Cleaning our registration database makes sense as we could have already registered package with outdated ABI hash.
Also note that original user's intent was to only keep build logs: https://archives.gentoo.org/gentoo-user/message/8357ed34c4f84123f0f682a8c3e5f290 This fact should help writing scarier description for FEATURES=keeptemp and advertise PORT_LOGDIR more :)
As Alan pointed out on the list, I see that PORT_LOGDIR does what I want, and with a more careful reading I could have seen that. I suggest changing the first occurence of "logs" to "build and elog logs" for the PORT_LOGDIR documentation, because the only occurrence of "build logs" near any of the PORT_LOGDIR references is at FEATURES=split-log; and PORT_LOGDIR says > Logs are created only when this is set. which I assumed must have been the case since elogs were getting saved.
Yeah, lets update the docs. Ebuilds should not have to support keeptemp. In fact, I am not aware of any valid use case for keeptemp, and this is why emerge issues a warning when keeptemp or keepwork is enabled.
Paging pms-bugs@. The PMS doesn't seem to make any guarantees about the initial contents of ${T}. It makes sense that ${T} would be an empty directory -- at least at the start of an emerge -- but would it also be valid for ${T} to contain random junk? If everyone agrees that ${T} should begin empty, maybe keeptemp can be updated to use a different path or something. But if there are no guarantees, then we may be stuck supporting the equivalent of FEATURES=keeptemp anyway.
(In reply to Michael Orlitzky from comment #6) > Paging pms-bugs@. > > The PMS doesn't seem to make any guarantees about the initial contents of > ${T}. It makes sense that ${T} would be an empty directory -- at least at > the start of an emerge -- but would it also be valid for ${T} to contain > random junk? > > If everyone agrees that ${T} should begin empty, maybe keeptemp can be > updated to use a different path or something. But if there are no > guarantees, then we may be stuck supporting the equivalent of > FEATURES=keeptemp anyway. Sorry for the late reply. PMS doesn't guarantee anything about T and TMPDIR. This is similar to normal /tmp I think.
