Hi, What happened to llvm 16.x? It was released three months ago. I tried to update the PKGBUILD locally to 16.x, this is what I got https://paste.rs/9R0Mk This issue should have been prevented if we used Source.tar.gz with a single PKGBUILD and should build different packages from this single source (like clang, lld, llvm, llvm-libs etc). Instead, we have three different PKGBUILD files (one for clang, one for lld, one for llvm+llvm-libs). why? I'm a long time arch user, when I started arch, I loved it because of how easy it was to take an official PKGBUILD file for an upstream project, bump the version and get the latest binaries in a single package, it was fairly simple. Now, lot of upstream projects was split into multiple packages (eg: qemu), I can understand the reason for the qemu package split, at least we have a single PKGBUILD to generate multiple qemu packages but this llvm split with multiple PKGBUILD is not helping us to move forward easily. It is stuck at 15.x. I think this is not supposed to be Arch's way. Thanks, Mohan R
On Sat, 2023-06-24 at 14:11 +0200, Mohan R wrote:
I'm a long time arch user, when I started arch, I loved it because of how easy it was to take an official PKGBUILD file for an upstream project, bump the version and get the latest binaries in a single package, it was fairly simple.
Hi, instead of expecting that using a PKGBUILD from the extra repository works by bumping the release, did you ever consider to follow the reddit advice [1] to use something provided by the AUR? I'm just asking since this is the aur-general mailing list. https://aur.archlinux.org/packages/llvm-git First Submitted: 2018-12-05 13:56 (UTC) Last Updated: 2023-06-18 11:14 (UTC) Perhaps a PKGBUILD between 2018 and 2023 allows to build llvm 16 by editing it to build the desired branch [2]. Regards, Ralf [1] https://www.reddit.com/r/archlinux/comments/yc68pp/what_happened_to_llvm_15/ [2] https://wiki.archlinux.org/title/VCS_package_guidelines#VCS_sources
Hi, On Sat, Jun 24, 2023 at 5:42 PM Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
Do you think anyone wants to risk screwing up their system after reading this first pinned comment[1]? I mostly use official PKGBUILD files if I ever want something new which is not available in the official repo. In my opinion, the method used in this AUR is supposed to be the official way of packaging llvm rather than splitting it into three PKGBUILDs. I'm not saying having three PKGBUILD files is wrong, there must be a good reason for having three PKGBUILD for llvm which I dont understand. All I'm saying is the current packaging of llvm is not helping to bring latest llvm quickly to the end user, we cannot use the current official PKGBUILD for llvm/llvm-libs to update to 16.x [1] https://aur.archlinux.org/packages/llvm-git#comment-822090 Thanks, Mohan R
Hello, Am Samstag, 24. Juni 2023 20:12:05 CEST schrieb Mohan R:
Hi,
On Sat, Jun 24, 2023 at 5:42 PM Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
Do you think anyone wants to risk screwing up their system after reading this first pinned comment[1]? I mostly use official PKGBUILD files if I ever want something new which is not available in the official repo. In my opinion, the method used in this AUR is supposed to be the official way of packaging llvm rather than splitting it into three PKGBUILDs.
It's not hard to install another version of LLVM in a different location or modify the PKGBUILD in doing so. I wonder why a git package doesn't do this in the 1st place, at least that's what I did when I had to package an older version of boost. Btw, you would have absolutely the same problem, too, when you increase the version in the upstream llvm PKGBUILDs, this case is an example against the practice of deriving from upstream PKGBUILDs without actually knowing what you're doing. Please inform yourself more about dynamic linking in general and ld.so.
I'm not saying having three PKGBUILD files is wrong, there must be a good reason for having three PKGBUILD for llvm which I dont understand. All I'm saying is the current packaging of llvm is not helping to bring latest llvm quickly to the end user, we cannot use the current official PKGBUILD for llvm/llvm-libs to update to 16.x
Maybe it is, it could still be a legacy remnant, though and it's good to question things looking for an explanation.
[1] https://aur.archlinux.org/packages/llvm-git#comment-822090
Thanks, Mohan R
Regards, Oskar
On Sat, 2023-06-24 at 20:12 +0200, Mohan R wrote:
Do you think anyone wants to risk screwing up their system after reading this first pinned comment[1]?
Oskar forestalled me, but my answer to this question is 1:1 with Oskar's reply: On Sat, 2023-06-24 at 20:28 +0200, Oskar Roesler wrote:
you would have absolutely the same problem, too, when you increase the version in the upstream llvm PKGBUILDs
[1] Lone_Wolf's pinned commented on 2021-08-16 11:26 (UTC): When you have this package installed applications that are built against repo-llvm/clang WILL fail unless they are rebuild against this package. This includes QTCreator, kdevelop , mesa, intel-compute-runtime, gnome- builder to name a few.
participants (3)
-
Mohan R
-
Oskar Roesler
-
Ralf Mardorf