tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: policy proposal: updating packages with many dependencies



* On 2025-03-20 at 12:54 GMT, Greg Troxel wrote:

The part of what I think you want that is harder is not updating to new
micros.  Updating seems ok stability wise, but it does trigger bulk
rebuilds.  It doesn't seem right to be to avoid bugfixes because of cpu
time, when rebuilding is a choice.

Some of the other changes in my tree are moving towards a split between cmake as a package intended for end users, and cmake as a build tool required by packages, as they are very different things.

cmake as a build tool should have all of code where it looks in hardcoded paths for headers/libraries, network support, etc ripped out, and updated very infrequently only when absolutely necessary and only after extensive testing. I'm also switching it to use its bundled dependencies to improve bootstrap support and avoid GCC dependencies.

cmake as an end-user package (and thus with a reverse dependency score of 1 instead of 10000) can be updated as many times as you like, and have all bells and whistles options enabled.

--
Jonathan Perkin                    pkgsrc.smartos.org
Open Source Complete Cloud   www.tritondatacenter.com


Home | Main Index | Thread Index | Old Index