(there's a mistake in metadata for the dchroot USE flag description btw) Since you know already which files collide, could you please add a blocker, on both sides (a USE-based blocker for dchroot I guess), or just last-rite dchroot if it's unmaintained and schroot can take its place? Thank you.
sys-apps/dchroot has been masked for removal in 30 days (and the metadata for schroot was fixed, thanks).
Please, don't delete dchroot from tree. Schroot isn't a replacement! Yes, it has more functions, but it is also uses 5x of memory. If it is an abandoned project it doesn't matter, it is a stable piece of software, and there isn't any bug except this one. I use it for managing my 6 chroots with no problems.
Created attachment 214617 [details] dchroot ebuild with correct RDEPEND This is a corrected ebuild for dchroot that "doesn't install if schroot is installed"/"prevent installation of schroot" with USE flag "dchroot". So both schroot ebuild and dhroot one now have right RDEPEND (schroot was ok). Pleas, don't remove dchroot, consider it as a "light version" of schroot.
What is more important than the memory waste of schroot: It forces pam. So if dchroot would be removed, it would become almost impossible to run a multi-arch (amd64+x86) desktop without pam - IMHO a disaster.
Created attachment 214822 [details, diff] dchroot-0.12.1.ebuild patch. This is the patch, so you don't need to open the previous archive.
+ 02 Jan 2010; Víctor Ostorga <vostorga@gentoo.org> -dchroot-0.10.ebuild, + dchroot-0.12.1.ebuild: + Removing Old version; adding blocker for collision with dev-util/schroot, + patch thanks to Zorzo Luca <lucazorzo@gmail.com> bug #298874 + Removing mask...
