| Summary: | coreutils PROVIDEs fileutils, but portage still wants to merge it | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Zach Welch (RETIRED) <zwelch> |
| Component: | Unclassified | Assignee: | Nicholas Jones (RETIRED) <carpaski> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | pebenito, seemant |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
carpaski -- can three packages "move" to one? We can fix this... But have to add virtuals to all profiles.
coreutils: PROVIDE virtual/{file,text,sh}-utils
virtuals: virtual/$1-utils sys-apps/$1-utils
Then change all references to the virtuals.
Heh, this is exactly what I proposed back when I switched the ARM profile to use coreutils. I am dying to do this and unmask coreutils, because I am very tired of having to extensively edit the portage tree everytime I emerge rsync + emerge world -uUDvp just to prevent fileutils from being pulled from the portage ebuild. Pretty please may I fix and commit these changes? I have tested them for months now and this solution works perfectly on ARM and x86. we're doing the upgrade another way. closing this. |
The ARM profile uses the new coreutils package; however, the existing PROVIDE in that ebuild, which lists sys-apps/fileutils, does not satisfy that RDEPEND in portage's own ebuild. This appears to be a bug in <=portage-2.0.48_pre2. Workaround: remove fileutils from portage's RDEPEND Easy solution: use virtuals for {file,text,sh-}utils. This actually makes sense looking at the virtual/mta use case: you want the two alternatives to block each other. These virtuals could be deprecated in the next release, once coreutils becomes the main/only choice. Hard solution: fix portage so that the coreutils PROVIDE works, which may be The Right Thing To Do.