Re: cmake version problem

[tlaronde%polynum.com@localhost]

Le Fri, Jul 21, 2023 at 08:48:12AM -0400, Greg Troxel a écrit :
> 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.

Is pkgsrc participating in GSoC for example? Because the pkgsrc guide
could do with an 'administrating packages' section or whatever to put
everything together: there is more than one way to do it (adding
packages), but there are not so many ways to do it right ;-)

It is enough work to require someone dedicated during a significant
amount of time but requires only a reasonable knowledge of user level
stuff. So it fits a GSoC project (it can also be a volunteer project
outside of GSoC, of course).
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C