Re: cmake version problem

[Greg Troxel <gdt%lexort.com@localhost>]

tlaronde%polynum.com@localhost writes:

> And for your other point, as suggested in another thread, you are
> indeed right (so it seems to me) about the various versions of the
> dependencies. Some pkgsrc tools verify all the dependencies and so
> it seems build the more recent version needed (if two dependencies
> depend on the same package but do not require the same version and one
> is more recent than the one installed that happens to satisfy the other
> package), and some tools don't: one end up with a dependency
> satisfied about what is currently installed, and then linking with
> a dshared lib of version M; and then another depedency wants an
> update, so the version of the dshared lib linked against by the previous
> dependency is removed and one has to hope that the ABI is compatible.

Yes, but what you are missing is that deciding that a newer version is
needed and building it (on a live system) necessarily involves "make
replace".  Just running make replace is unsound if there is an ABI
change.  This is why pkg_rolling-replace exists; it figures out the set
of unsafe_depends packages and rebuilds them in order.

pbulk does the same thing at a very high level; after a package is built
then anything that depends on it needs to be rebuilt.  The difference is
that pbulk uninstalls things, and all builds are done in a clean minimal
manner.  If you want the build output and you don't want the system --
that is great.  If you need to use the system while this is happening --
that's why pkg_rr exists.

The practice of generally not updating is not sound, unless one does
pkg_rr (perhaps without -u) to completion after you do make replace.
But building other things will trigger rebuilds of dependencies, which
will cause the build to fail.  Which comes back to the only reasonable
options for maintaining a system when you update pkgsrc being pbulk and
pkg_rr.