Re: [gentoo-user] Use Flags and Updating

[Alan McKinnon <alan.mckinnon@gmail.com>]

On 06/06/2014 12:44, Rich Freeman wrote:
> On Thu, May 22, 2014 at 3:54 AM, Marc Joliet <marcec@gmx.de> wrote:
>> I think nowadays one would prefer --keep-going, which automatically resumes on
>> failure (and recomputes the dependency tree!), and prints a list of failed
>> packages when it's finished. However its output is more verbose than just "ok"
>> and "failed" (it'll print the build.log if it's only one package, IIRC).
> 
> Hmm, after using this script for some time I found a problem with this
> approach.  If you use --buildpkgonly and ---keep-going then emerge
> won't build a single thing if anything in the list is missing a
> build-time dependency.  The script I posted will try to emerge
> everything individually so at least some of the packages will be
> compiled.
> 
> That seems like a bug in --buildpkgonly.  If you use it with
> --keep-going it should at least compile the packages that aren't
> missing build-time options.  I'll file that as a bug if it isn't
> already there...



I don't think it's a bug, it's more like a difference in interpretation.
From the man page:


       --buildpkgonly (-B)
              Creates binary packages for all ebuilds processed  without
              actually merging the packages.  This comes with the caveat
              that all build-time dependencies must already  be  emerged
              on the system.
       --keep-going [ y | n ]
              Continue as much as possible after an error. When an error
              occurs,  dependencies are recalculated for remaining pack‐
              ages and any with unsatisfied dependencies  are  automati‐
              cally dropped. Also see the related --skipfirst option.


So, decisions about --buildpkgonly are made at the start of an emerge
and --keep-going kicks in only when an error occurs at the end, and the
former must have higher precedence than the latter.

It doesn't make sense to expect portage to change it's behaviour about
it's initial decisions just because you also have an entirely unrelated
option set that is only a convenience in the event of a build failure.
That seems to me too much of an unexpected side effect


-- 
Alan McKinnon
alan.mckinnon@gmail.com