| Summary: | reemerging a *-bin package destroys the installation | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Georgi Georgiev <chutz+bugs.gentoo.org> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | major | CC: | sascha-gentoo-bugzilla |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Heh, that's a lovely one :) I'm working on trying to centralize the CONTENTS data, which would avoid issues like this, and also deal w/ instances where a file is owned by multiple packages. Not quite ready yet though. Meanwhile, suggestions for an intermediate hack to block this behaviour would be appreciated :) I gave an intermediate workaround solution suggestion already: after src_install() is complete, a "find ${DISTDIR} -print0 | xargs -0 touch" is performed. That ought to do the trick.
|
Portage tracks new files by their mtime and md5. However, if you install a *-bin package, the files a very often install with the mtime from the package. This means that a subsequent "removing the already installed version of the package" would remove the files that have just been installed. Reproducible: Always Steps to Reproduce: 1. emerge mozilla-firefox-bin 2. emerge mozilla-firefox-bin Actual Results: Half of your mozilla-firefox-bin installation is lost. Expected Results: Nothing should have been removed, as the packages are identical. I guess, portage should make sure that files are installed with a present timestamp (if this is when portage collects the timestamps) in $DISTDIR. This means that installations like the one of mozilla-firefox-bin (quoting: "mv ${S} ${D}/opt/firefox"} should not happen, or, as an alternative and a better idea, all files in ${DISTDIR} have to be "touch"ed before collecting timestamps and md5sums. I am curious if something similar happens when using "emerge -K".