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 <heyrict@zohomail.com> 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, notify@aur.archlinux.org 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/

I was not aware of programs like Blender writing into there

Blender depends on intel-oneapi-compiler-shared-runtime-libs[^1] that is a subset of `intel-oneapi-basekit`. This is installed on all PCs no matter if intel graphics is used. One option here to avoid the `intel-oneapi-basekit` is to have the intel cpp compiler & headers as make dependencies, and runtime libs as dependencies, just as how the blender[^2] package did. Maintaining a specific version of oneAPI libraries is fine for sure, which is commonly used when the libraries the package depends on are not compatible with arch's packages. e.g. 3D Slicer relies on python 3.9, while the upstream python is 3.14. So the package have to build another version of python itself to avoid incompatibility[^3]. IMO, as `oneapi` is stable and quite big in size, the first option may sound better to me. But anyway, since we don't have a maintained sycl version of llama.cpp at present, either option would be fine. Keep the package smaller in size is in lower priority in compared with having no maintained versions. Any effort you make to build the package is well appreciated. [^1]: https://archlinux.org/packages/extra/x86_64/intel-oneapi-compiler-shared-run... [^2]: https://archlinux.org/packages/extra/x86_64/blender/ [^3]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=3dslicer#n104 Regards, Zhenhui Xie On 5/13/26 10:49 PM, Can Tosun wrote:

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 <heyrict@zohomail.com> 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 <heyrict@zohomail.com> 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, notify@aur.archlinux.org 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/