Hi,
I noticed that there are clang14 and clang15 packages in the repository
but if I do `apk add clang` it installs *some* clang that happens to be
version 15 but there is no `clang` package in the repositories.
How does that work? I couldn't find anything about this behaviour on the
wiki. When clang16 comes out, will I get a update? Does this work for
all digit-suffixed packages?
-prokop
On Wed Feb 1, 2023 at 6:04 PM CET, Prokop Randacek wrote:
> Hi,
>
> I noticed that there are clang14 and clang15 packages in the repository
> but if I do `apk add clang` it installs *some* clang that happens to be
> version 15 but there is no `clang` package in the repositories.
>
> How does that work?
for clang14/15 specifically, the packages contain:
provides="clang=$pkgver-r$pkgrel"
so clang15 provides a clang=15 .. and clang14 provides a clang=14 ..
that is, a "clang" virtual with a specific version.
if you add, i.e.
$ apk add 'clang<15'
you would get clang14.
> I couldn't find anything about this behaviour on the
> wiki. When clang16 comes out, will I get a update?
yes unless you have some other constraints like noted above
> Does this work for all digit-suffixed packages?
no. but some like llvm do the same.
and this isn't generally wanted, most things do not have multiple versions at
all, etc. we just had a need to keep around the older clang (not just llvm)
during 15.x (purely only for postgresql), so that happened :)
realistically, now i'll probably maintain a same clang version of whatever llvm
is in the repos at the same time (so 14/15 now, 16 when it comes, etc), and
once the llvms' have no revdeps both are dropped (preferring latest as always).
such multiversioning and packages with absolute conflicts are not fun to
manage :-) the only reason i did it is because otherwise llvm15 entirely would
have to be reverted for postgres. but now that i wrote it out, it'll probably
stay for clang.
>
> -prokop