it occationally gets to me that if I merge anything that requires several deps to merge, I can get a couple of merges before something breaks. KDE is a nice example, if I say: "emerge kde" I'd expect KDE to merge, or not. today we can get parts a couple of KDE-packages installed before one breaks, and halts the merge. what I'd _like_ is that everything gets built and found okay before it gets merged. for large things like KDE this will require a good deal of space in the buildroot, but I think that's a small price to pay. it would also be nice for people who aren't interested in the dependencies when they install something like Xine. if it anything breaks, the rest of the packages are really pointless to have about, and there isn't any easy way of cleaning them out either.
emerge -p depclean I have yet to finish reverse dependancies.
depclean solves a different problem. the real problem is that users expect to be able to treat a single emerge as a single operation. emerge xine either merges xine or does nothing. even if the partial install can be removed either by reading logs or using depclean I'd personally like to see the package tool itself deal with this by avoiding the problem in the first place. this implementation is also something we see even in most other packaging tools. it might be practical to have a "--sequential" switch or something to prevent portage from dealing atomicly with the merge, but it's not critical. one can always loop emerge for each package anyway.
another thing I thought about. it's not the entire merge that is atomic. it should be implemented so that packages that are interdependent form a transaction. hence, if I say: emerge --update kde perl and I get a dozen packages related to kde and two related to perl, and that neither of the packages depend on eachother, then portage should treat this as two transactions. one for the kde packages and one for the perl packages. this is rather vital so emerge --update world doesn't totally croak because one package, which nothing else depends on, fails to build. it also saves space under the buildroot compared to treating every merge as a single transaction. as for the implementation, would it be feasable to implement this feature something like this: - for each ebuild being merged, keep a list of all builds it requires to build in the current merge process. - as a package build is finished, the list of current merges is checked. if nothing depends on this package check what depenencies it has that have also been built during this merge. if any, install them, before eventually installing yourself. if there where depenencies on the current package, leave the package in the buildroot, basically postponing src_install(). early in the morning this seems to be all the extra logic that is needed. the question is if it is doable to implement in portage today. I'll try to look at the source and see if I can produce some code.
This isn't reasonable, at least for the near future. KDE is built in sections. Don't expect a metapackage to be atomic.