4 ms·

> what does -dev -doc etc. really mean? -dev packages ship the header files for C/C++ libraries, and in some odd cases also static libraries. -doc packages sh

> what does -dev -doc etc. really mean? -dev packages ship the header files for C/C++ libraries, and in some odd cases also static libraries. -doc packages ship documentation (unsurprisingly). Usually they only exist for things like libraries and interpreteres, where the documentation can be sizable and is only needed by a (small) subset of the users that have the package installed. > I often need a -dev package for stuff I'm not even building for some reason That's because to compile something that links against a library, you need to have the header files available. > why do some libs tack on a 'lib' at the front while some do not Aside from a few leftover historical oddities (primarily zlib), all shared libraries should be prefixed with lib. > why are package versions often seemingly unrelated to upstream versions? They should be. Exceptions are made for "native" packages (which usually provide Debian-specific software or integrations) and upstreams that don't really follow any versioning scheme. > sometimes packages come is multiple versions (like GCC) and yet often they don't In the steady state there should be only one version of every package. During the transition to a new version, especially of very core packages such as GCC, there might temporarily be more. It's unfortunately happened in the past that multiple versions ended up in stable, but that was because the Linux kernel required a specific GCC version. > for instance i just looked up lxqt which is listed as version 13... I don't know what version that corresponds to upstream.. 1.13? The LXQT package is a "native" package that only provides integration between Debian and LXQT, and as such it doesn't follow LXQT's version numbering. If you instead look at any actual LXQT software (e.g. lxqt-session), they follow the upstream versioning (0.14). I agree that it's a bit confusing, but it's a result of the development process.

geokon 7y ago
Thank you for taking the time to explain :) And yeah, zlib is a weird one. It's listed as zlib1g sometimes and the files are libz from what I remember I have a followup if you don't mind. I'm trying to rack my brain for old confusions I've had... For instance I look up libssl. There is a libssl-dev, but no corresponding libssl. There are other libssl libs but all the names are inconsistent: libssl1.0.0 with no libssl1.0.0-dev and then there is a libssl1.0.2, but it has no libssl1.0.2-dev haha. But I do see a libssl1.0-dev and when I click through it have 1.0.2 as a dependency... So what's going on?
- pja 7y ago
  The zlib1g name has something to do with the libc5 to libc6 transition that affected all of Debian back circa the year 2000 I think. The libssl-dev thing is because (usually) you can only have the headers installed for a single version of a library. So you get libssl-dev. But you can have multiple binary versions installed, to support other packages that may have been compiled with older versions of the library with incompatible ABIs & that haven’t been recompiled or updated to the latest version yet. So you have a -dev package that depends on the latest binary package. Sometimes, you have headers that live in their own versioned directories, so you can compile against older library releases (maybe there’s an API change & not all your packages have been updated to the new API yet). Hence the libssl1.0-dev, which put headers for the old libssl version in a subdirectory in Debian stretch (I think?) so they didn’t interfere with the ones for the new version.
- Denvercoder9 7y ago
  > And yeah, zlib is a weird one. It's listed as zlib1g sometimes and the files are libz from what I remember Fun fact: the "g" in the zlib1g package names comes from the transition to the GNU C library back in 1997, and zlib hasn't had any ABI-incompatible changes since then (ABI-breaks are the point where libraries are usually renamed, so that you can (temporarily) have both installed while users of the library are migrated to the new version). If it would be introduced nowadays it would just be called libz1, consistent with other libraries. > I have a followup if you don't mind. I'm trying to rack my brain for old confusions I've had... For instance I look up libssl. There is a libssl-dev, but no corresponding libssl. There are other libssl libs but all the names are inconsistent: libssl1.0.0 with no libssl1.0.0-dev and then there is a libssl1.0.2, but it has no libssl1.0.2-dev haha. But I do see a libssl1.0-dev and when I click through it have 1.0.2 as a dependency... So what's going on? The usual structure is to have libfoo-dev with the development headers of the newest version, and then libfooX (with X the version number) with the shared libraries. There's usually only one of each, but during development older versions of the shared library might be around so that you can run binaries using them until they've been recompiled to link against the new version. There sometimes have been exceptions if it's very hard to get all software ported to the new version in time, but that's quite rare. As far as I can see for OpenSSL, Debian 8 (jessie) shipped OpenSSL 1.0.0 (libssl-dev and libssl1.0.0). Debian 9 (stretch) had both OpenSSL 1.1 as default (libssl-dev and libssl1.1), and (as one of those exceptions) also OpenSSL 1.0 for legacy software (libssl1.0.2 and, again as an exception because the libssl-dev name is already taken, libssl1.0-dev). Debian 10 (buster), the current version, ships only OpenSSL 1.1.0 (libssl-dev and libssl1.1). (In the case of OpenSSL it's even more confusing because 1.0.1 was a backward-compatible release with 1.0.0, but 1.0.2 wasn't. So the packages named 1.0.0 were actually version 1.0.1. Fortunately upstream has fixed their versioning scheme since then, so it will get better. That's also the reason old versions included the full version number, and now there's only the major and minor version -- since patch releases are compatible.)

geokon 7y ago

Thank you for taking the time to explain :) And yeah, zlib is a weird one. It's listed as zlib1g sometimes and the files are libz from what I remember I have a followup if you don't mind. I'm trying to rack my brain for old confusions I've had... For instance I look up libssl. There is a libssl-dev, but no corresponding libssl. There are other libssl libs but all the names are inconsistent: libssl1.0.0 with no libssl1.0.0-dev and then there is a libssl1.0.2, but it has no libssl1.0.2-dev haha. But I do see a libssl1.0-dev and when I click through it have 1.0.2 as a dependency... So what's going on?

pja 7y ago
The zlib1g name has something to do with the libc5 to libc6 transition that affected all of Debian back circa the year 2000 I think. The libssl-dev thing is because (usually) you can only have the headers installed for a single version of a library. So you get libssl-dev. But you can have multiple binary versions installed, to support other packages that may have been compiled with older versions of the library with incompatible ABIs & that haven’t been recompiled or updated to the latest version yet. So you have a -dev package that depends on the latest binary package. Sometimes, you have headers that live in their own versioned directories, so you can compile against older library releases (maybe there’s an API change & not all your packages have been updated to the new API yet). Hence the libssl1.0-dev, which put headers for the old libssl version in a subdirectory in Debian stretch (I think?) so they didn’t interfere with the ones for the new version.
Denvercoder9 7y ago
> And yeah, zlib is a weird one. It's listed as zlib1g sometimes and the files are libz from what I remember Fun fact: the "g" in the zlib1g package names comes from the transition to the GNU C library back in 1997, and zlib hasn't had any ABI-incompatible changes since then (ABI-breaks are the point where libraries are usually renamed, so that you can (temporarily) have both installed while users of the library are migrated to the new version). If it would be introduced nowadays it would just be called libz1, consistent with other libraries. > I have a followup if you don't mind. I'm trying to rack my brain for old confusions I've had... For instance I look up libssl. There is a libssl-dev, but no corresponding libssl. There are other libssl libs but all the names are inconsistent: libssl1.0.0 with no libssl1.0.0-dev and then there is a libssl1.0.2, but it has no libssl1.0.2-dev haha. But I do see a libssl1.0-dev and when I click through it have 1.0.2 as a dependency... So what's going on? The usual structure is to have libfoo-dev with the development headers of the newest version, and then libfooX (with X the version number) with the shared libraries. There's usually only one of each, but during development older versions of the shared library might be around so that you can run binaries using them until they've been recompiled to link against the new version. There sometimes have been exceptions if it's very hard to get all software ported to the new version in time, but that's quite rare. As far as I can see for OpenSSL, Debian 8 (jessie) shipped OpenSSL 1.0.0 (libssl-dev and libssl1.0.0). Debian 9 (stretch) had both OpenSSL 1.1 as default (libssl-dev and libssl1.1), and (as one of those exceptions) also OpenSSL 1.0 for legacy software (libssl1.0.2 and, again as an exception because the libssl-dev name is already taken, libssl1.0-dev). Debian 10 (buster), the current version, ships only OpenSSL 1.1.0 (libssl-dev and libssl1.1). (In the case of OpenSSL it's even more confusing because 1.0.1 was a backward-compatible release with 1.0.0, but 1.0.2 wasn't. So the packages named 1.0.0 were actually version 1.0.1. Fortunately upstream has fixed their versioning scheme since then, so it will get better. That's also the reason old versions included the full version number, and now there's only the major and minor version -- since patch releases are compatible.)