1 |
On 06/06/2014 12:44, Rich Freeman wrote: |
2 |
> On Thu, May 22, 2014 at 3:54 AM, Marc Joliet <marcec@×××.de> wrote: |
3 |
>> I think nowadays one would prefer --keep-going, which automatically resumes on |
4 |
>> failure (and recomputes the dependency tree!), and prints a list of failed |
5 |
>> packages when it's finished. However its output is more verbose than just "ok" |
6 |
>> and "failed" (it'll print the build.log if it's only one package, IIRC). |
7 |
> |
8 |
> Hmm, after using this script for some time I found a problem with this |
9 |
> approach. If you use --buildpkgonly and ---keep-going then emerge |
10 |
> won't build a single thing if anything in the list is missing a |
11 |
> build-time dependency. The script I posted will try to emerge |
12 |
> everything individually so at least some of the packages will be |
13 |
> compiled. |
14 |
> |
15 |
> That seems like a bug in --buildpkgonly. If you use it with |
16 |
> --keep-going it should at least compile the packages that aren't |
17 |
> missing build-time options. I'll file that as a bug if it isn't |
18 |
> already there... |
19 |
|
20 |
|
21 |
|
22 |
I don't think it's a bug, it's more like a difference in interpretation. |
23 |
From the man page: |
24 |
|
25 |
|
26 |
--buildpkgonly (-B) |
27 |
Creates binary packages for all ebuilds processed without |
28 |
actually merging the packages. This comes with the caveat |
29 |
that all build-time dependencies must already be emerged |
30 |
on the system. |
31 |
--keep-going [ y | n ] |
32 |
Continue as much as possible after an error. When an error |
33 |
occurs, dependencies are recalculated for remaining pack‐ |
34 |
ages and any with unsatisfied dependencies are automati‐ |
35 |
cally dropped. Also see the related --skipfirst option. |
36 |
|
37 |
|
38 |
So, decisions about --buildpkgonly are made at the start of an emerge |
39 |
and --keep-going kicks in only when an error occurs at the end, and the |
40 |
former must have higher precedence than the latter. |
41 |
|
42 |
It doesn't make sense to expect portage to change it's behaviour about |
43 |
it's initial decisions just because you also have an entirely unrelated |
44 |
option set that is only a convenience in the event of a build failure. |
45 |
That seems to me too much of an unexpected side effect |
46 |
|
47 |
|
48 |
-- |
49 |
Alan McKinnon |
50 |
alan.mckinnon@×××××.com |