On Mon, 28 Mar 2005 19:56:30 -0600 Scott Jones <[EMAIL PROTECTED]> wrote: | If you search gmail (it being that you save these mails) ...I am | pretty sure you will find a post by Ciaran (damn dont rip my head off | C. if I spelled your name wrong) that says it is bad and it all boils | down to cache. So I wouldn't do it but if you really want to | understand why ask ciaran and risk his wrath...
Noooo, cache is bad for sync + merge at the same time. Parallel merge is bad for different reasons. Simple example, which is easy to understand but not entirely valid since we generally check for this kind of thing... Existing state: libfoo-1 is installed. User: merge libfoo User: merge fnord libfoo: dep resolver decides to upgrade to libfoo-2 fnord: dep resolver decides to install fnord libfoo: fetch, unpack fnord: fetch, unpack libfoo: configure starts fnord: configure starts libfoo: configure done, make starts fnord: configure: check for libfoo: found libfoo-1 fnord: configure done, make starts fnord: make building with libfoo-1 headers libfoo: make done, installing libfoo: install done libfoo: autocleaning libfoo-1 libfoo: merge complete fnord: linking against libfoo-1 And then stuff explodes, since libfoo-1 isn't there any more. The dep resolver won't necessarily see this as a problem either, assuming libfoo isn't slotted and that fnord doesn't need specific libfoo versions. Usually the breakages are quite a bit more complex than that. -- Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools) Mail : ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm
pgpCi8AaKMT3m.pgp
Description: PGP signature
