Re: cmake version problem

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

tlaronde%polynum.com@localhost writes:

>> While you are technically correct that these limits should perhaps be
>> different:
>> 
>>   pkgsrc as used by just about everybody who contributes has an
>>   expectation that packages are reasonably up to date, and ~nobody
>>   spends time worrying about trying to build packages with 2023Q2
>>   sources with installed binary packages from 5 years ago (cmake was
>>   updated to 3.10 in March of 2018!).  The standard approach is to pkgin
>>   ug from binary packages, do your own pbulk and use that, use pkg_rr,
>>   or something equivalent.
>
> I'm not complaining: I'm only stating and this could avoid puzzling 
> "bug" reports so help you (the pkgsrc developers or programmers).

I didn't take it as a complaint.

> And as a matter of "how" it can happen to be so: I'm using pkgsrc only
> for some packages and, for my own software, I use neither pkgsrc nor
> cmake.

Certainly it can happen.  I was just trying to point out that having a
pkgsrc installation and not keeping it up to date leads to encountering
edge cases that are not encountered by the set of people that fix things.

>>[...] 
>> Currently the requirement (in /usr/pkgsrc/mk/tools/replace.mk) is
>> 
>>   cmake>=2.8.1nb1
>> 
>> and indeed that is unreasonably crufty.
>> 
>> We could change it to 3.19, reflecting end of 2020 pkgsrc, and a version
>> recent enough that any upstream that can't build with 3.19 is IMHO
>> buggy.
>
> IMHO (because I don't contribute except for patches), this seems a
> reasonable compromise: won't update cmake every other week; but should
> ensure that it is reasonably near the version used when bulk building on
> binary servers so that builds successing in this up-to-date environment
> should succeeds even on systems dragging reasonably behind.

Yes, that is consistent with my thinking.

> And BTW, x11-links has been a problem too from time to time, because
> when upgrading a node, it has to be rebuilt but an admin is not aware of
> it.

When you upgrade the base system across major versions, you basically
have to choose between:

  upgrade all packages whether you care about them or not

  don't build any new packages

  go off the rails of sound behavior (because packages will have varying
  system libs linked)

One helpful strategy is to remove all packages that are not installed
intentionally and not a dependency of an intentional package.  I do this
with pkgin with summaries based on my own builds, patrol "pkgin sk" and
remove with uk, and then "pkgin ar".