| 1 |
David Leverton <levertond@××××××××××.com> posted |
| 2 |
200805312034.51915.levertond@××××××××××.com, excerpted below, on Sat, 31 |
| 3 |
May 2008 20:34:51 +0100: |
| 4 |
|
| 5 |
> On Saturday 31 May 2008 20:25:42 Hemmann, Volker Armin wrote: |
| 6 |
>> New in pkgcore: |
| 7 |
>> --ignore-failures: |
| 8 |
>> [snip] |
| 9 |
>> |
| 10 |
>> people who asked for a similar functionality in paludis were called |
| 11 |
>> stupid. (asking for skipfirst equivalent) |
| 12 |
> |
| 13 |
> [dleverton@shiny-one ~] $ paludis --help [snip] |
| 14 |
> --continue-on-failure Whether to continue after a fetch or install |
| 15 |
> error |
| 16 |
> if-fetch-only If fetching only (default) |
| 17 |
> never Never |
| 18 |
> if-satisfied If remaining packages' dependencies are satisfied |
| 19 |
> if-independent If independent of failed and skipped packages |
| 20 |
> always Always (UNSAFE) |
| 21 |
|
| 22 |
I don't have a particular dog in this fight, but that's not the same |
| 23 |
thing. --skip-first allows the admin to react to whatever when wrong, |
| 24 |
try to fix it, and use the skip option only if he decides it's |
| 25 |
warranted. IOW, it's sort of interactive, tho over time. It appears |
| 26 |
this option must be added at the beginning, before one knows there'll be |
| 27 |
an error, and independent of what that error might be. |
| 28 |
|
| 29 |
(I'm assuming paludis creates a log of what failed, so one can try them |
| 30 |
again later, after fixing the problem or getting a package update or |
| 31 |
whatever. If not, that's another difference, as the --skipfirst option |
| 32 |
allows one to (manually) create such a list, and in fact that's what I |
| 33 |
use it for when doing an emerge --emptytree after upgrading gcc, for |
| 34 |
instance. The old packages often still work fine so don't /have/ to be |
| 35 |
upgraded, but with a list, as they are fixed to work with the new |
| 36 |
version, they can be retried and if successful, stricken from the list, |
| 37 |
thus gradually shrinking the number of packages not compatible with the |
| 38 |
new gcc version.) |
| 39 |
|
| 40 |
I did see the log where the --skipfirst functionality request was called |
| 41 |
stupid. I never quite understood why. If the above was already there |
| 42 |
and considered equivalent, I can see why the request might be called |
| 43 |
stupid, but nobody bothered to explain that if it was indeed the case, so |
| 44 |
both the requester and all the others that ended up seeing that IRC log |
| 45 |
missed out on the real answer. Unfortunately, that sort of "missing out" |
| 46 |
has become somewhat of a pattern, altho if/when the explanation /does/ |
| 47 |
come, it's usually very well reasoned out. It's just worse than pulling |
| 48 |
teeth to get it, sometimes, even on the devel list after being asked |
| 49 |
repeatedly by multiple devs, which is where I see the pattern repeated |
| 50 |
most often, since as a good admin, I lurk there to see what's coming down |
| 51 |
the road before I hit it. |
| 52 |
|
| 53 |
-- |
| 54 |
Duncan - List replies preferred. No HTML msgs. |
| 55 |
"Every nonfree program has a lord, a master -- |
| 56 |
and if you use the program, he is your master." Richard Stallman |
| 57 |
|
| 58 |
-- |
| 59 |
gentoo-amd64@l.g.o mailing list |
Archives