| Summary: | Non-Virtuals as virtuals are bad | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Veiko Kukk <veiko> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | major | CC: | azarah, dev-portage, luke.hart, mholzer, mr_bones_, seemant, streck |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Veiko Kukk
2003-07-21 05:12:26 UTC
Multiple people have had similar results. Install coreutils, and when removing fileutils or whatever, they lose stuff. As a side note, http://dev.gentoo.org/~avenj/bins/ has an i686-compiled coreutils-5 for anyone who reads this and needs it. Thinking a bit ahead I managed to avoid this mess. Here's how I did it-
1)built a binary coreutils
2)unmerged {text|file|sh}-utils
3)untarred my package to /opt (this is where things are tricky,as binaries aren't prefixed correctly, namely usr/ or bin/ instead of /usr/ and /bin/ which makes getting on to your system correctly. After all you just lost rm and cp etc.)
4)edit /etc/profile to include /opt/usr and /opt/usr/bin and /opt/bin (must source after!!!)
5)edit /usr/bin/emerge after bang to read /opt/usr/bin/env instead of /usr/bin/env
6)At this point you can either merge your pre-built binary or emerge it form source.
7) Most importantly, refix your path in /etc/profile and set /usr/bin/emerge header back to normal.
Kinda tedious, maybe these steps can help develop a transparent solution?
if you emerge coreutils to the latest version and then clean out the old textutils/fileutils/sh-utils this shouldnt happen this is also what *should* have happened when you upated your system >if you emerge coreutils to the latest version and then clean out the old
>textutils/fileutils/sh-utils this shouldnt happen
this is the way it happens! first it upgrades to coreutils and then removes those files when removing old textutils/fileutils/sh-utils.
*** Bug 27993 has been marked as a duplicate of this bug. *** I would like to add to this by saying that if one makes the mistake of unmerging the trio of packages coreutils supercedes then you really will have a big mess - look at this: sirius root # emerge unmerge fileutils textutils sh-utils -p >>> These are the packages that I would unmerge: sys-apps/coreutils selected: 5.0-r3 protected: none omitted: none >>> Packages in red are slated for removal. >>> Packages in green will not be removed. If you unmerge each of the three individually then it works okay. I did this on one of my cluster nodes without the '-p' and it f**k'd everything up good! :-) I suppose there is some virtual package-ness going on here. Just thought I'd pass this one along. Scott Just a little more detail: on a system whose last sync was couple of weeks ago coreutils-4.5.11-r1 fileutils-4.1.11-r2 textutils-2.1-r1 sh-utils-2.0.15-r1 "emerge unmerge fileutils textutils sh-utils" works as a user would expect I understand that this is *not* something one should do yet - it was just a test. After sync'ing today, system wants to upgrade to coreutils-5.0-r3 and tells user to get rid of the three packages it replaces. before upgrading coreutils the "emerge unmerge fileutils textutils sh-utils" works as expected. Also probably not a good idea. however, after upgrading coreutils (and you've seen the message to remove the three packages) "emerge unmerge fileutils textutils sh-utils" **does what it is supposed to** The problem is if you do it again - for some reason - like I did. If you "emerge unmerge fileutils textutils sh-utils" a second time it will unmerge coreutils. I manage quite a few machine and forgot that I had unmerged the old packages already. In any case this kind of thing probably should not happen - at the very least to prevent forgetful people like me from borking their systems. ------- Additional Comments From azarah@gentoo.org 2003-18-09 11:49 EST ------- Ok, unfortunately the real fixes, etc went on without any of it ever reaching this bug. Seemant and I talked about this, and at the end he added the new skeleton fileutils/sh-utils/textutils that depended on coreutils, which finally fixed this issue. I am however not sure about the following result: -------------------------------------- nosferatu gcc # emerge unmerge fileutils -p >>> These are the packages that I would unmerge: sys-apps/coreutils selected: 5.0-r4 protected: none omitted: none >>> Packages in red are slated for removal. >>> Packages in green will not be removed. nosferatu gcc # emerge fileutils -p These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N ] sys-apps/fileutils-4.1.11-r2 nosferatu gcc # ------------------------------ Suggestions ? azarah: the reason you're seeing that behavior is because someone put PROVIDE values into these packages at some point ... if you review the virtuals file you should see things like this: sys-apps/fileutils sys-apps/coreutils sys-apps/textutils sys-apps/coreutils sys-apps/sh-utils sys-apps/coreutils the problem is this: (1) no one ever defined the behavior of what is *supposed* to happen when you do a PROVIDE on a non-virtual ... the PROVIDE was originaly (afaik) meant just to satisfy the issue of virtuals ... someone at some point noticed you could also stick regular packages in there ... (2) currently, when you do a PROVIDE like that, you see the behavior you showed in the output ... weird things happen if you try to do portage operations like that ... *** Bug 30032 has been marked as a duplicate of this bug. *** So basically portage should not unmerge the package providing the non-virtual package when you specify the non-virtual package as package to unmerge ? Hope you got the meaning =) well at this point in time all the non-virtuals have been removed and we've gotten beyond this i think |
