Summary: | sys-apps/portage: FEATURES=keepwork causes emerge to re-use WORKDIR despite different USE | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Roman Žilka <roman.zilka> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=937037 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Roman Žilka
2013-05-21 14:06:58 UTC
(In reply to comment #0) > ... and started filling BUILDDIR/image with the files already present in > BUILDDIR/work from the previous compilation. That, however, was with > different USE flags. Emerge should've detected that before the second run > and started the compilation a-fresh. You have to clean it yourself when you use FEATURES=keepwork. Rather than change the behavior, I would prefer to simply remove the feature. I haven't removed it because some people may find it useful as-is. Well, it's still beter as-is than gone. But it might just wipe the BUILDDIR clean, like it's a regular failed build. I'm guessing keepwork users more often than not want to inspect the unpacked sourcecode and possibly re-compile a package at a later time, not just have the compiled sources there to re-merge them into ROOT repeatedly. But then - the current behavior has been there for some time and those who make use of it may expect it. (In reply to comment #2) > But then - the current behavior > has been there for some time and those who make use of it may expect it. Exactly. For people who use FEATURES=keepwork, cleaning WORKDIR can potentially be a *destructive* operation, because they could have things in there that they expect to be protected. Why do you want to enable FEATURES=keepwork anyway? How is it useful to you? When there's a problematic pkg, I sometimes want to inspect the source tree, see what went wrong, make a patch etc. Then I either re-compile the sources by hand in the workdir, or I re-emerge - either that's necessary or at least more comfortable. I have to call rm -rf $TMPDIR by hand to avoid the current workdir re-use strategy. The current keepwork behavior is something I never had any use for. When I know I'm going to need to re-merge (re-fill $ROOT with files) a given pkg repeatedly, I make a tbz2. This happens a few times a year. What I originally called for, however, is not a droppage of the workdir outright before any new emerge. It's not a bad feature that emerge can detect the pre-compiled sources there. It's just that it should then ideally also detect that now I no longer want to install and use pkg[use1], but pkg[use2] which may have a different ./configure call, different resulting binaries etc. But currently emerge does not detect it and I can't picture anyone who expects this, including those who somehow make use of keepwork for store-and-reuse purposes. Makes me think again if it really is better as-is than gone... Tough call. I have no strong opinion either way about the keepwork staying or going. For the troubleshooting workflow described, I always use the ebuild command directly instead of emerge. So, as long as you can use the ebuild command, I see no real reason to keep the keepwork feature other than potentially convenience. Well, FWIW, the ebuild command suffers from the same bug. When the pkg in /work has src_compile() finished, so it seems, then a subsequent call of "ebuild pkg.ebuild compile [install] [...]" performs no compilation despite any USE change. I have to keep in mind that I must call "ebuild ... clean compile" when I change USE. When you run the ebuild command, you should get a warning message like this when it re-uses the existing environments:
>>> Existing ${T}/environment for 'grep-2.14' will be
>>> sourced. Run 'clean' to start with a fresh environment.
I think that warning message is good enough. Cleaning ${WORKDIR} can be a destructive operation, so it's left to the user to decide.
For similar reasons, emerge produces the following warning for FEATURES=keepwork:
* WARNING: The FEATURES variable contains one or more values that
* should be disabled under normal circumstances: keepwork
I think we can improve the documentation for keepwork, to clarify the reason that it prevents cleaning, and to clarify that things like USE changes are not accounted for.
|