Bugzilla Bug 13179

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.