David Leverton <levertond@googlemail.com> posted
200805312034.51915.levertond@googlemail.com, excerpted below, on Sat, 31
May 2008 20:34:51 +0100:

> On Saturday 31 May 2008 20:25:42 Hemmann, Volker Armin wrote:
>> New in pkgcore:
>> --ignore-failures:
>> [snip]
>>
>> people who asked for a similar functionality in paludis were called
>> stupid. (asking for skipfirst equivalent)
>
> [dleverton@shiny-one ~] $ paludis --help [snip]
> --continue-on-failure Whether to continue after a fetch or install
> error
> if-fetch-only If fetching only (default)
> never Never
> if-satisfied If remaining packages' dependencies are satisfied
> if-independent If independent of failed and skipped packages
> always Always (UNSAFE)

I don't have a particular dog in this fight, but that's not the same
thing. --skip-first allows the admin to react to whatever when wrong,
try to fix it, and use the skip option only if he decides it's
warranted. IOW, it's sort of interactive, tho over time. It appears
this option must be added at the beginning, before one knows there'll be
an error, and independent of what that error might be.

(I'm assuming paludis creates a log of what failed, so one can try them
again later, after fixing the problem or getting a package update or
whatever. If not, that's another difference, as the --skipfirst option
allows one to (manually) create such a list, and in fact that's what I
use it for when doing an emerge --emptytree after upgrading gcc, for
instance. The old packages often still work fine so don't /have/ to be
upgraded, but with a list, as they are fixed to work with the new
version, they can be retried and if successful, stricken from the list,
thus gradually shrinking the number of packages not compatible with the
new gcc version.)

paludis always creates logs, even if everything goes fine. you could disable them but it's unsafe.

I did see the log where the --skipfirst functionality request was called
stupid. I never quite understood why. If the above was already there
and considered equivalent, I can see why the request might be called
stupid, but nobody bothered to explain that if it was indeed the case, so
both the requester and all the others that ended up seeing that IRC log
missed out on the real answer. Unfortunately, that sort of "missing out"
has become somewhat of a pattern, altho if/when the explanation /does/
come, it's usually very well reasoned out. It's just worse than pulling
teeth to get it, sometimes, even on the devel list after being asked
repeatedly by multiple devs, which is where I see the pattern repeated
most often, since as a good admin, I lurk there to see what's coming down
the road before I hit it.

the --skipfirst is stupid. it just skips the first package that failed. the problem is the following: if a package has failed and the following is dependant on it the skipfirst just resumes portage and then issues an error of deps not met and stops. this would stop your emerge and you would need to do the emerge again, since a --resume doesn't find anything to resume. the continue-on-failure is a little more intelligent:
normally, if a package has a dependance on a package that failed (even if not strictly on the version that failed to install) the package would have been skipped. the other option is to skip a package if the deps installed are satisfied (so if you have a dep on >=openldap-2.3.x and openldap-2.4.1 fails to install the packages that with the first option would have been skipped would now install, since openldap-2.3.5 is present). the other continue options are stupid and most likely to do some real harm so i don't tend to consider them useful. at the end of the emerge process paludis prints the packages that have failed and gives a command line to resume the emerge operation, including the various logs of failure and the messages from the packages that have been succefully merged.
this option doesn't prevent errors, but tells paludis to continue the work if possible and let the eventual errors to be controlled at the admin return. pkgcore seems to do something similar, by looping the --skipfirst option, but that is more like the continue-on-failure always with the skip of the first package on the resume. it's a bit stupid, but still more useful than the --skipfirst of portage.