[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1116323: marked as done (libllama-dev: pkgconf file in hidden location)

Your message dated Thu, 25 Sep 2025 22:51:37 +0200
with message-id <[🔎] 8e940d38-7e92-439d-8a2b-d1299a179f0b@debian.org>
and subject line Re: Bug#1116323: libllama-dev: pkgconf file in hidden location
has caused the Debian Bug report #1116323,
regarding libllama-dev: pkgconf file in hidden location
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1116323: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116323
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libllama-dev
Version: 5882+dfsg-3; reported 2025-09-25
Severity: normal

Thank you so so much for packaging llama.cpp and ggml. I look forward to
working a bit more with it and seeing about possible R-based
frontends. Discussing this with someone else I mentioned pkgconf / pkg-config
and tried to check only to see that a) yes of course it ships a .pc file in
the -dev package but b) it appears to be in a non-standard location:

  root@3eaed7568463:/# pkgconf --list-all | grep llama
  root@3eaed7568463:/# 

yet once I 'make it known' it all works:

  root@3eaed7568463:/# pkgconf --with-path=/usr/lib/x86_64-linux-gnu/llama/pkgconfig/ --cflags llama
  -I/usr/include/llama 
  root@3eaed7568463:/# pkgconf --with-path=/usr/lib/x86_64-linux-gnu/llama/pkgconfig/ --libs llama
  -L/usr/lib/x86_64-linux-gnu/llama -lggml -lggml-base -lllama 
  root@3eaed7568463:/# 

I have relied for a few projects on the fact that pkgconf would automagically
find the .pc file so I think we want this in one of

  /usr/lib/x86_64-linux-gnu/pkgconfig/
  /usr/lib/pkgconfig/
  /usr/share/pkgconfig/

and 'TIL there are several' so here it is probably the first one as the
library is likely the best. Oddly I also see

  /usr/share/ggml/pkgconfig/ggml.pc

which is similarly 'tucked away' so `pkgconf --list-all` does not see it, but
hides in 'share'.

It would be lovely if you could move the .pc files.

Cheers, Dirk


-- System Information
Debian Release: trixie/sid
Kernel Version: Linux paul 6.14.0-29-generic #29-Ubuntu SMP PREEMPT_DYNAMIC Thu Aug  7 18:32:38 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

-- 
dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

--- End Message ---
--- Begin Message --- 
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/

--- End Message ---
Reply to: