Re: Bug#1116323: libllama-dev: pkgconf file in hidden location
On 2025-09-25 21:47, Dirk Eddelbuettel wrote:
> Hm. I do not think that is very clever. It basically just renders the library
> much less deployable.
>
> And I am not being argumentative here but why did you bother packaging it
> (which from the complexity of the upstream setup is surely non-trivial work)
> when at the end of the day you do not want user of the library use it?
The goal was to ship the llama.cpp *utilities*. In the first version of
this [1], there was only bin:llama.cpp, with no library or -dev packages
at all.
ggml was factored out because it is the most complex part of the package
(building various backends and so on), and it is also needed by
whisper.cpp. We didn't want to duplicate the work. And this is still
experimental; it's still possible that we might need to embed again
after all.
The library and -dev packages were split out by request because one big
monolith package with every possible component and test is sub-optimal
to someone who just needs llama-server, for example. This request seemed
reasonable.
And it's prep work for the time when the libraries actually become
stable.
> I am being serious here. I was planning to work "on top" and now I can't
> because I would have to re-invent library discovery on every possible distro
> or deployment.
Lacking stability, you probably couldn't do that anyway, even if every
distro shared the same installation layout. You'd still have to work out
how to deal with different versions.
I understand that you have a use case for the libraries, but I don't
understand the challenge here. Whatever you wanted to do, you
can still do, just add one more argument to pkg-config or cmake.
> I guess I could hardcode those paths
Those private paths won't change, if that helps.
> In reality the library likely moves too fast anyway.
Yes, that is my point. I (or any other deployment) can't give you
predictability/stability if it's not there to give in the first place.
Best,
Christian
PS: I'll be updating llama.cpp and ggml to recent versions over the weekend.
[1]: https://tracker.debian.org/news/1640550/accepted-llamacpp-5151dfsg-1exp2-source-amd64-into-experimental/
Reply to: