Hi David, On Mittwoch, 17. November 2010, David Kalnischkies wrote: > the message I meant was: > > > E: Error, pkgProblemResolver::Resolve generated breaks, this may be > > > caused by held packages. > > that should be an error message from APT and I can't trigger this one - > it would be a serious problem if APT would really print that on a normal > dist-upgrade try (without holds of course)…
Ah. (piuparts doenst use holds.)
> I wouldn't say force, I would "just" recommend it. Its not a strict
> requirement as this specific case is handled by the recommends
> which are activated by default. Other cases will lead to the removal
> of the offending package, which is awkward, but not fatal as it can
> be reinstalled if needed after the upgrade. Also, as said, the notes
> already recommend a split upgrade by first 'upgrade' and then
> 'dist-upgrade' which should take care of getting a new apt & friends
> in as well in most (not all) cases.
Right. I could piuparts do that too, though I'm not convinced I should, unless
the notes explicitly say one has to.
> >> P.P.S.: Offtopic, but Holger, why does piuparts uses --fix-broken
> >> switch?
> > where do you see this?
> "apt-get -yf dist-upgrade" in your steps -- the -f stands for --fix-broken
Ah. piuparts creates a piuparts-depends-dummy package for the first
installation of the package, for reasons which are hidden in the history of
the project... ;-) This packages has all the depends (and conflicts) of the
package to be tested and is installed with dpkg. Then apt-get install -f is
run... I _assume_ thats why the -f is also used for apt-get dist-upgrade.
This is code I took over from Lars and it's not the only part where I havent
fully understood the reasons behind it. But there is work on it being done:
#588041 #603453
(The master-slave mode of piuparts has another package relationship resolving
mechanism...)
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
