> > This situation varies depending on whether program "D" is SLOTted or > not. When it has different SLOTs for different versions, multiple > versions can be installed side-by-side. There is usually a good reason > for doing so (for example, breaking programs that depended on D-1 in > D-2). > > You could try `emerge depclean -p` to see whether any of the versions of > "D" are candidates for removal. Another option would be to check the > ebuilds of all packages depending on "D" to see whether they depend on a > specific version (=3Dversion) or just >=3Dversion. > > I can't think of any better ways offhand. >
Some more data points. In this specific case i have nmh wanting =db-1.85 (which is SLOT=1) and postfix wanting db=4.1 (SLOT=4.1). I tried a emerge -UDve world just to get everything compiled with the latest gcc etc. What happened was that nmh's compilation halted saying that it couldn't link to the db (db.so.2 missing if memory serves). Alright, checked the nmh .ebuild file and noticed DEPEND =db-1.85. emerge of that one seems to knock the 4.1 one out of the waters (and 4.1 unmerges 1.85). So it seems the two packages don't install nicely side-by-side (at least not tha way i do it. I'm a SLOT illiterate). The 4.1 one does seem to claim 1.85 compatibilit though since it creates a bunch of symlinks 1.85 -> 4.1. Whatever compatibility it has is not enough to make nmh happy though. Bottom line is that everything user to work ok before I tried -UDve world, now I can't seem to get it back in order. intercepting the "Waiting 5 seconds before starting..." thing and not proceeding with the unmerge does the trick though, it seems. I'm not sure of the db slotting is since it apparently is a bit invasive in the -e scenario. On the other hand the nmh packaging does not seem to have the right knobs to check for libs... ideas anyone? /A -- [EMAIL PROTECTED] mailing list
