Hacker News Reader

Comment by zjp | Hacker News Reader

Maybe I'm just too ignorant to know the pattern that determines whether I need to specify 'dev' and 'version' on a package or some random trailing '1' or '0', but the first linux distro with a sensible and consistent naming scheme for packages is the one that wins my heart.

`libgnutls-dev` `libgtk-3-0` `libwayland-server0` `libxcb1` `libx11-6` `libffi-dev` `libncurses5-dev`

View on HN

-dev contains the headers, that ones pretty easy.

The number is a version for when they provide more than one that can be installed at once (excepting where it's part of the library name, presumably like xcb1).

I.e. at some point you could probably install libgtk-3-0 and libgtk-2-$something at the same time. They likely leave it that way when they get rid of libgtk-2 so that existing tutorials that reference libgtk-3-0 don't fail because the package is now libgtk.

The libwayland-server0 one does get me, I don't know why there's a 0 at the end. I do know that in /var/lib there is often the same library with various .$number endings, but I've never looked into what that accomplishes.

> but I've never looked into what that accomplishes

ABI versioning.

ABI stands for application breakage interface

Oh, that makes perfect sense. I assumed there was a valid reason, and that makes far more sense than anything I could think of offhand.

Except something as fundamental as libwayland should not have an ABI version because the goal should be to never break the ABI. Well, it should also be called libX11.so.6 and extend that ABI instead of making a new ABI.

Separating binaries from sources is a Debian convention. If you're just using a library, non-dev is sufficient. If you're developing with that library, you'll also want -dev, which will install the headers.

Nothing special about the trailing 1 or 0; that's just part of the package name/version.

Arch and its derivatives (mostly) don't have any of that.

Though -dev means stuff only needed when developing against it.

Number means major version number (so compatibility number). This way you can easily install multiple major versions as dependencies for different packages without clashing or breaking.

Arch Linux packaging is the only one that makes sense.

If I install openssl, I want everything that upstream ships, which means command line tools, headers, libraries, man pages.

The Debian/Ubuntu convention is terrible, and anachronistic. Disk space is cheap, my time is not.

You might but most people don't want OpenSSL headers cluttering up their system just because they installed something that needs to make TLS connections.

If you are building a program, install the -dev package. Numbered -dev packages are usually not relevant; there should be an unnumbered one that forwards if needed.

During the build of a program, you record which numbered suffix (= ABI version, should be the same as the .so.N suffix but that's not how you look it up; this allows you to install multiple incompatible copies of the library and they will be used by the appropriate, though distros usually prune these after each major release) is used. This should be automatic. (if there's more than one number, all but the last are part of the library name itself. There might be exceptions for BSD-style libraries?)

When installing, you should be automatically using the dependency you recorded during the build.

There's gobolinux, which in my view solves everything and isn't as complicated as nix... nobody cared.

This.

And, as for the -dev packages:

1) As always, a tooling issue (aka why is there no IDE for this?) 2) A design issue: no sub-packages/"aspects"

Reply on news.ycombinator.com