This type of problem has already bitten me once before. Perhaps a policy or mechanism should be created to deal with this sort of problem? I think the rpm-4.0.4.ebuild installed a patched version of libpopt. rpm-4.0.4-r1.ebuild simply has a dependancy on a certain version of libpopt, which is a separate ebuild package. When rpm-4.0.4 was cleaned, libpopt bit the dust, breaking things that depended on it. (like rsync) So, my thinking is that libpopt was installed as a package, rpm-4.0.4 overwrote it with its custom libpopt, and since rpm-4.0.4-r1 doesnt contain libpopt, libpopt got removed when the older package was unmerged. Paul
Yes, that must the be the source of the problem. Unfortunately I see no good way to deal with it without adding major new functinality to portage. This isn't a common problem but a good case might be made in favour of a generic solution. Maybe something on the order of REMERGE="popt" in the rpm ebuild - you get the idea. A feature proposition might be made, but unfortunately I don't deal in potrage features and don't have any bright ideas about this at present. If you do, they'd be welcome - please open a new bug with any submision, or post on the mailing lists or even ask a dev on irc. A bug about it shouldn't be my property, however, so I'm reassigning it back to bug-wranglers, whence it will probably go to drobbins as a portage feature proposition. Please flesh it out if you can.
I Think that there might be a second resolution to this: Check the consistency of the "DEPEND" packages. If any of those packages are "broken" ie, the .so's have the wrong md5 sum or other such thing, then rebuild them, if not, don't rebuild. This will add a sort of "self-healing" feature to portage, instead of blindly forcing a rebuild. Though, a blind force rebuild is a good thing in several cases, fex. "We need python with expat" but depends on Expat + python doesn't rebuild python with expat.... because python is already there. so this might be seen as a partial solution.
a simple check + warn might be useful as a first step ... of course a rewrite of the way CONTENTS is stored would be required, i think it might be too slow to parse all the CONTENTS files when merging a new package
*** This bug has been marked as a duplicate of 28228 ***
