Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

2008/5/31 Duncan <1i5t5.duncan@×××.net>:

> David Leverton <levertond@××××××××××.com> posted
> 200805312034.51915.levertond@××××××××××.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.

-- 
dott. ing. beso