deb-shlibs(5)

📦
version 1.23.11 · 19 versions
, in arch rolling

💖 deb-shlibs — the little file that tells everyone who needs your shared lib 💖

okay so bestie, this is deb-shlibs(5), straight out of the dpkg suite, and honestly? it's giving "small file, huge responsibility." let's get into it 🫶

✨ NAME ✨

deb-shlibs — the Debian shared library information file. that's it, that's the vibe. 👑

🌸 SYNOPSIS 🌸

debian/shlibs, debian/binary-name.shlibs, DEBIAN/shlibs

those are the spots it lives in, no cap. 📍

🦋 DESCRIPTION 🦋

so shlibs files do one iconic thing: they map shared library names and versions (aka SONAMEs) to dependencies that are suitable for a package control file. literally matchmaking, but for packages. 💅

The rule that matters: a shlibs file must be shipped in the same binary package as the shared libraries described inside it. why? so the mappings are guaranteed to actually match the shared library being described, and so the shlibs file can be found from the package that owns the shared library. it's a whole trust thing. 🔥

one entry per line, babe. blank lines are not allowed. nope, not even one. lines starting with a # character count as commentary and get ignored (finally, a place to rant ✍️). every other line has gotta have this format:

[type:] library version dependencies

so the library and version fields are whitespace-delimited, but the dependencies field just keeps going all the way to the end of the line — main character energy, it takes up space. 🎀 the type field is optional and normally not needed, so like, don't stress about it.

the dependencies field has the same syntax as the Depends field in a binary control file — peep deb-control(5) if you need the full tea. 🍵

⭐ SONAME FORMATS ⭐

the supported SONAME formats are:

name.so.version

and

name-version.so

where name is usually prefixed by lib. 🧚

now the fun part — which one do you use? the first one (name.so.version) tends to be used by shared libraries with stable interfaces. the second one (name-version.so) is for shared libraries with unstable interfaces, where the whole version becomes part of the SONAME and needs to be specified in full when linking against those libraries. no shortcuts, sorry bestie. 😭

🔥 EXAMPLES 🔥

say you've got a typical library package named libcrunch1 that provides one library whose SONAME is libcrunch.so.1. its shlibs file might read:

libcrunch 1 libcrunch1 (>= 1.2-1)

and here's the detail people always miss 👀 — the dependencies must mention the most recent version of the package that added new symbols to the library. in this example, new symbols were added to version 1.2 of libcrunch. and before you ask: no, that's not the only reason the dependencies might need to be tightened. it's just the obvious one. 🙈

🌈 SEE ALSO 🌈

go read those, iykyk. 📚

💀 real talk: no blank lines in the file. not a single one. i love you but i will not defend you if you add one.

and that's the whole page, bestie! this was deb-shlibs(5) from the dpkg suite, version 1.23.11-dirty, dated 2026-09-09. go forth and map those SONAMEs. periodt. 💜🎀

📦 where this page comes from