On Sat, Nov 04, 2006 at 04:56:31PM -0800, Zac Medico wrote: > Francesco Riosa wrote: > > could it be the other way around ? Use the saved and if it fail try to > > use the current? > > > > Reason for this is that otherwise you need to maintain in the tree code > > to un-merge very old packages, needlessy bloating the current, plus > > experience teach this is very error prone. > > > > There is a problem however with this approach, you can't fix bug where > > the (original ebuild) exit code is "success" but the behaviour is "damn > > bugged". > > It gets a little messy if we have to check exit codes like that.
Can't rely on exit codes coming back from phases anyways; ebuild/eclass devs don't force it to be 0 for success- last time I tried checking exit code, just wound up making things bail out a lot due to false positives. > If pkg_prerm() fails with the saved ebuild/eclasses, then we substitute > everything that we can from the live tree and then try again? What > about if pkg_prerm() succeeds with the saved ebuild/eclasses, but > then pkg_postrm() fails? I suppose we would substitute everything > that we can from the live tree at that point. It's a little messy > but I guess we can do that if that's how people think it should behave. This approach should *never* be tried; reasons- You're going to have fork for every search attempt to protect the original env. from getting crap from failing eclasses Even if you find a combination that doesn't explode, there is no gurantee it'll actually run completely; whats nasty is if it *partially* runs; (pre|pkg)(inst|rm) are not tracked in any fashion, so any changes they do t the livefs isn't tracked. Further, ebuilds/eclasses *do* pair prerm and postrm changes; swapping in a different phase func their requires ebuild/eclass devs to always rely on the same state vars between those phases (not going to happen). This situation gets massively worse when (yes when) dyanmic eclasses (able to be removed, api can change) hits, since at least with the current static eclasses folks are forced to keep things compatible. Remove that restriction, and this proposed approach becomes a much worse minefield- end result there is that dynamic eclasses cannot be implemented until whats proposed above is backed out. > Anyway, portage-2.1.2 is nearing a final release and it may be the > stable version of portage for 2007.0, so it might be a good idea to > make it start saving eclasses.tbz2 for installed packages now (even > if it doesn't actually use them for anything). I imagine that it > will just be a bzipped tarball containing an "eclass" directory with > all of the inherited eclasses inside. Env handling isn't something that should be rushed (this includes slipping in eclasses.tbz2, which I posit will not be used); the data needed has been there for a *long* time already, use it. ~harring
pgp7vmoqx5YIx.pgp
Description: PGP signature
