Okay, I was not aware of programs like Blender writing into there, I assumed it's literally just people running local AI that likely will only have one package installed anyway. In that case maybe I'll also move the oneAPI folder to /opt/llama.cpp-sycl/oneapi/, that way everything the package installs is located there apart from the bins. That should really make it a next to zero possible conflicts install apart from having another llama.cpp build, right?
-------- Original Message -------- On Wednesday, 05/13/26 at 09:39 Zoho <[email protected]> wrote: Thank you for your instant response. I'm glad these recommendations can be of some help to you. I have to warn you again that the `intel-oneapi-basekit` is not the only package that writes to `/opt/intel/oneapi`. There are many others (see `pacman -Ss oneapi`) and some famous packages such as blender depend on them. Please be *very careful* if you truly want to write into that directory rather than simply depend on `intel-oneapi-basekit`. Regards, Zhenhui Xie On 5/13/26 2:24 PM, Can Tosun wrote: > 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/
