Good morning Zhenhui, Thank you for the feedback, I will get to work on addressing your points shortly.
For point 1, I plan to add intel-oneapi-toolkit to the conflicts array since true coexistence under pacman is not practical given the shared target path. I feel like the full toolkit only has a use for the handful of people that actually develop with oneAPI, which in reality wouldn't use this package anyway. The actual intended enduser will almost certainly never touch any of these tools. For point 2, very valid point so I plan to move the llama.cpp install prefix to /opt/llama.cpp-sycl so that libggml.so and other shared libraries stay out of /usr/lib entirely, with RPATH set so the binaries find their libraries without any environment changes. Binaries will be symlinked into /usr/bin as usual. For point 3, you are also correct and I plan to add !buildflags to options and simplify the build according to the official documentation. Regarding llama.cpp-sycl-f16, I am happy to delay the deletion request by a month or two as you suggest. However I would prefer not to adopt it. There are already four SYCL llama.cpp packages in the AUR, now five due to mine but my aim was to keep it up to date since I use it on my B70 myself and to minimize confusion for the end user by only providing one definitive package. I hope you understand. Thanks again for taking the time to write. Best regards from Germany Can Tosun -------- Original Message -------- On Wednesday, 05/13/26 at 03:39 Zoho <[email protected]> wrote: Thank you for your packaging on `llama.cpp-sycl`. I am the current maintainer of `llama.cpp-sycl-f16`. This package is currently unmaintained, as the original maintainer txtsd orphaned it and I don't have access to an intel dGPU now. It would be great if we could have a single well-maintained llama.cpp sycl package that works under different settings. However, I would kindly recommend delaying the deletion of package `llama.cpp-sycl-f16` for a month or two. Despite out of date, it is verified to work on the PC of txtsd and me, so that users will have some fallbacks in case the latest version don't compile on their PC. Here are my recommendations on your package. Hope it could be some help to you: - You said that your package bundled *essential oneAPI components* without need to installing the full `intel-oneapi-toolkit`. Do they conflict if a person have to install both on their PC? - `libggml.so`, if installed to /usr/lib, could have conflict with other packages (e.g. `https://aur.archlinux.org/packages/whisper.cpp`). Probably installing that shared object to a different folder (e.g. /opt/llama.cpp-sycl) and override LD_LIBRARY_PATH would solve the conflict. - In my previous experiment, `makepkg` won't setup the environment correctly by `source "${oneapi_root}/setvars.sh"` if `!buildflags` was not set. Was it solved in the latest oneapi? If you could maintain compatibility with previous versions (e.g. dependencies on `intel-oneapi-toolkit`), I would be happy to hand over `llama.cpp-sycl-f16` to you. Regards, Zhenhui Xie On 5/12/26 2:38 PM, [email protected] wrote: > cantosun99 [1] filed a deletion request for llama.cpp-sycl-f16 [2]: > > llama.cpp-sycl-f16, llama.cpp-sycl-f16-git, llama.cpp-sycl-f32 and > llama.cpp-sycl-f32-git are all out of date since they have last been > updated a year ago or even orphaned, llama.cpp-sycl aims to fix this > and should therefore replace the four. > > [1] https://aur.archlinux.org/account/cantosun99/ > [2] https://aur.archlinux.org/pkgbase/llama.cpp-sycl-f16/
