Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 13179 - atomic merge / unmerge operations.
Summary: atomic merge / unmerge operations.
Status: RESOLVED WONTFIX
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All All
: High major (vote)
Assignee: Nicholas Jones (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-01-03 13:28 UTC by Terje Kvernes
Modified: 2011-10-30 22:36 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Terje Kvernes 2003-01-03 13:28:56 UTC
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.
Comment 1 Nicholas Jones (RETIRED) gentoo-dev 2003-01-04 16:34:35 UTC
emerge -p depclean

I have yet to finish reverse dependancies.
Comment 2 Terje Kvernes 2003-01-04 17:00:57 UTC
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.
Comment 3 Terje Kvernes 2003-01-12 01:06:14 UTC
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.


Comment 4 Nicholas Jones (RETIRED) gentoo-dev 2003-02-03 04:47:57 UTC
This isn't reasonable, at least for the near future.
KDE is built in sections. Don't expect a metapackage to be atomic.