> | 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)
Ok, one at a time then. - Grant -- gentoo-user@gentoo.org mailing list
