Re: [gentoo-user] Multiple simultaneous emerges
Nick Rout wrote: Not usually, but you might run into problems, if for example a library changes via one ebuild while another is compiling against it. perhaps. I do it all the time, no probles so far. I am not sure what will happen if the same package is in both lists, ie if emerge X has Y as a dependency, and emerge Z has the same dependency. On Mon, 2005-03-28 at 17:22 -0800, Grant wrote: You might notice that sometimes it tries to unpack a package that is currently being compiled if you emerge the same 'class'. Obviously that results in a 'pulled the chair under my arse' effect and the compile fails because previously compiled objects are missing :P -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Multiple simultaneous emerges
On Wed, 2005-03-30 at 20:16 +0100, Nicolai Guba wrote: Nick Rout wrote: Not usually, but you might run into problems, if for example a library changes via one ebuild while another is compiling against it. perhaps. I do it all the time, no probles so far. I am not sure what will happen if the same package is in both lists, ie if emerge X has Y as a dependency, and emerge Z has the same dependency. On Mon, 2005-03-28 at 17:22 -0800, Grant wrote: You might notice that sometimes it tries to unpack a package that is currently being compiled if you emerge the same 'class'. Obviously that results in a 'pulled the chair under my arse' effect and the compile fails because previously compiled objects are missing :P Agreed, it pays to be careful, I would not do two complex ebuilds with many dependencies at the same time. And definitely check that both aren't going to emerge the same dependency. However, as an example, I was doing an install the other day, and emerged stuff lioke vixie-cron and mc at the same time. In fact at one point I was using 4 consoles with 2 or 3 emerges going and setting up rc files in the 4th. -- gentoo-user@gentoo.org mailing list -- Nick Rout [EMAIL PROTECTED] -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Multiple simultaneous emerges
Ciaran McCreesh wrote: [snip] 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. At this point run a revdep-rebuild should fix the situation also for situation more complex than that, right? -- No problem is so formidable that you can't walk away from it. ~ Charles M. Schulz But sometimes run fast is better ~ Francesco R. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Multiple simultaneous emerges
Neive question - if it is such a bad idea, shouldn't there be a check for it? Maybe a second overlapping emerge should come up with a Warning: emerge already running - continue (y/N)? message if a lock file exists to indicate that the portage tree is busy... DigbyT On Tue, Mar 29, 2005 at 03:27:48AM +0100, Ciaran McCreesh wrote: 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... N, 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 -- Digby R. S. Tarvin [EMAIL PROTECTED] http://www.digbyt.com -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Multiple simultaneous emerges
On Tue, 29 Mar 2005 11:08:16 +0200 Bastian Balthazar Bux [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | 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. | | At this point run a revdep-rebuild should fix the situation also for | situation more complex than that, right? Hrm. A revdep-rebuild fixes (usually) dynamic linking errors on things that are already installed. To fix linking errors of the kind I just mentioned, all that is necessary is to not try to merge more than one thing at once. -- Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpjsoh1XJx5E.pgp Description: PGP signature
Re: [gentoo-user] Multiple simultaneous emerges
On Tue, 29 Mar 2005 10:50:15 +0100 Digby Tarvin [EMAIL PROTECTED] wrote: | Neive question - if it is such a bad idea, shouldn't there be a check | for it? Maybe a second overlapping emerge should come up with a | Warning: emerge already running - continue (y/N)? | message if a lock file exists to indicate that the portage tree is | busy... Portage is non-interactive unless you --ask. So a better suggestion would be for it to bail out unless a --allow-parallel (say) switch is provided. -- Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp8BGn09RtOD.pgp Description: PGP signature
[gentoo-user] Multiple simultaneous emerges
Is there anything wrong with multiple simultaneous emerges? - Grant -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Multiple simultaneous emerges
On Mon, 2005-03-28 at 20:22, Grant wrote: Is there anything wrong with multiple simultaneous emerges? That's a definate no-no! -- Phil Our 2nd CD: http://www.cdbaby.com/naomisfancy Naomi's Fancy performances: http://naomisfancy.virtualave.net/schedule.html -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Multiple simultaneous emerges
Not usually, but you might run into problems, if for example a library changes via one ebuild while another is compiling against it. perhaps. I do it all the time, no probles so far. I am not sure what will happen if the same package is in both lists, ie if emerge X has Y as a dependency, and emerge Z has the same dependency. On Mon, 2005-03-28 at 17:22 -0800, Grant wrote: Is there anything wrong with multiple simultaneous emerges? - Grant -- gentoo-user@gentoo.org mailing list -- Nick Rout [EMAIL PROTECTED] -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Multiple simultaneous emerges
On Mon, 28 Mar 2005 17:22:26 -0800, Grant [EMAIL PROTECTED] wrote: Is there anything wrong with multiple simultaneous emerges? - Grant -- gentoo-user@gentoo.org mailing list Grant 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... Scott Jones -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Multiple simultaneous emerges
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... N, 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
Re: [gentoo-user] Multiple simultaneous emerges
| 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... N, 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
