On Sep 11, 2005, at 1:50 PM, Martin Costabel wrote:
Dave Vasilevsky wrote:
You can almost certainly get around this for now by manually removing libquicktime0, then building python24. After that the original command should work, or at least get farther.
Sure, but it's a bug anyway. It works even when I just update python24; it is then able to remove libquicktime0 by itself. Only after the preceding useless swapping in and out it doesn't work. It seems to me BuildConflicts always only work right once at the beginning of a build process, but they are only detected later, in general, when it's too late.

Martin,

Yup, it definitely is still a bug. You're right about why it happens: Fink only deals with BuildConflicts at the very start of the build process.

I intend to fix this bug sooner or later. The way I'd like it to work is kinda like the BuildDepends swapping: immediately before building a package, Fink checks for BuildConflicts and removes them. Then just after the build, they're reinstalled. Dan has been looking into a way to uninstall buildlocks after a build, regardless of whether it succeeds or fails--so I'll probably use whatever mechanism he comes up with to reinstall the BuildConflicts after.

and so on, and fink -v install fink said

Could not resolve inconsistency! The following dependency errors remain: Unsatisfied dependency in gdal-shlibs: postgresql80 (>= 8.0.2-12) | postgresql80-ssl (>= 8.0.2-12) Unsatisfied dependency in gdal: postgresql80 (>= 8.0.2-13) | postgresql80-ssl (>= 8.0.2-13)

Just some explanation of what this is all about. Due to a bug in dpkg, installing a package can sometimes cause unsatisfied dependencies.

As an example, say you have foo and foo-shlibs version 1.0-1 installed, where foo Depends: foo-shlibs (= 1.0-1). If a new version 2.0-1 is released, then 'fink update foo-shlibs' used to update foo- shlibs to 2.0-1 but leave foo at 1.0-1, which is broken.

To prevent this, Fink (from CVS HEAD) now refuses to install anything unless it determines that all dependencies on the system will be satisfied. Currently there's a primitive problem-resolver algorithm in Fink, which can deal with the specific situation above but not much else. The general solution is running 'apt-get -f install', as you did.

If anybody has a problem with this new way of doing things, now's the time to tell me. I could make Fink less strict if people need the ability to have some broken deps.

Dave

Attachment: PGP.sig
Description: This is a digitally signed message part

Reply via email to