7 ms·

Disclaimer: Have been an apt shadow for a couple years and ran some PPAs on both launchpad and private servers. Personally, I think the approach that upstream

Disclaimer: Have been an apt shadow for a couple years and ran some PPAs on both launchpad and private servers. Personally, I think the approach that upstream Debian uses in order to not include the headers of libraries with the binary builds is wrong. Nobody has time to deal with over 30 GIGAbytes of hard drive memory that is just there because I wanted to rebuild a damn library of 20kB. That is a total fail, architecture- and build-system wise. As long as Debian separates between distributed binaries, and -dev packages which include all source codes and headers - I would not recommend it for software development. This is the exact reason of PPA fatigue, where end users have sometimes dozens of versions of the same library installed that is also an absolute security nightmare to begin with. Reproducible builds are worth nothing if everybody has to use a PPA of some random untrusted blog post on the internet (omgubuntu anyone?) because Debian's packages are too outdated. Usually those PPAs are heavily outdated as they are built once and then abandoned for years. Libraries are not upgradeable due to how other packages depend on them. They cannot be rebuilt without having to rebuild the whole operating system (have to rebuild X again? Well, gonna stop here then.) Sorry for the rant, but I think in order for DUR to work in practice, these conceptual flaws have to be fixed upstream first.

zxzax 5y ago
I'll try to respond to some of your comments, but I'll admit I'm always somewhat confused by rant posts. I never really understood PPAs, that seems like an Ubuntu thing that was not ever suggested to use in debian. If you want to stay on bleeding edge for packages, the suggestion would be to use debian sid. I'm not sure what you mean 30 GB of memory. How is that related? And how would merging the -dev packages into the library packages solve it? IMO there are problems with the Debian approach but I wouldn't say that's one of them -- a worse problem to me is that things like cross-compiling/multi-arch mostly requires chrooting which is a lot less convenient than the approach used by something like Nix.
- andrewshadura 5y ago
  You don't need to chroot for cross-compiling, Debian supports multi-arch for most of the packages. You just install the cross-compiler, the cross-libc and all native development packages for the architecture you're building for.
  - zxzax 5y ago
    Last time I tried that I had bad problems with package conflicts trying to overwrite files, but it was a while ago and maybe I was doing something wrong, I'll give it another shot.
viraptor 5y ago
> As long as Debian separates between distributed binaries, and -dev packages which include all source codes and headers - I would not recommend it for software development. Is that the case for some specific languages? -dev packages for C and other compiled libraries do not include the full source code of the library. Normally they only include the headers, pkgconfig, and similar files. > Libraries are not upgradeable due to how other packages depend on them. Got some examples where it's a problem and not an actual dependency issue?
- cookiengineer 5y ago
  > Got some examples where it's a problem and not an actual dependency issue? Try to recompile mesa or say, just the demos (aka glxgears) :) Worst case scenario for Debian dependencies.
  - viraptor 5y ago
    I meant an example of what the issue is. Glxgears seems to have reasonable dependencies (https://packages.debian.org/buster/mesa-utils https://packages.debian.org/buster/mesa-utils) gl1 and glu1 are not even restricted on versions.
  - seba_dos1 5y ago
    I regularly recompile mesa on my Debian-based phone and I'm not exactly sure what you mean. It goes painless.
tinus_hn 5y ago
So you would rather have them waste that exact same amount of space on every computer, just so you don’t have to download it when you want to build a package?
- creshal 5y ago
  I don't have any Debian machine that doesn't end up with build-essential and dozens of header packages installed; it just comes up too often. Adding the header files directly to the packages saves time and frustration, and probably even saves space since a lot these packages are 50% overhead (dpkg meta files, db entries, etc.) by size.
  - tinus_hn 5y ago
    I refuse to believe that these meta files and database entries are occupying anywhere near a relevant amount of space.
    - creshal 5y ago
      Relatively. Absolutely, it's negligible - because the space consumption of header files is also negligible. It's such a bizarre design choice to split out a single 30 line .h file into a separate package.
  - _d7dt 5y ago
    I don't install build-essential on a server, in a container, on a VM, etc. It really matters in those places. If you combine them then you lose the ability to deploy a small rootfs.
    - creshal 5y ago
      Servers, VMs etc. always end up getting build-essential to handle random python/ruby/npm/... package installations, as the shipped versions are hopelessly outdated and creating your own debian packages for all of them is about as enjoyable as performing appendix surgery on yourself. Multi-stage builds do make it a bit easier to get rid of them for containers, yes, but during the build stage it's still required.

zxzax 5y ago

I'll try to respond to some of your comments, but I'll admit I'm always somewhat confused by rant posts. I never really understood PPAs, that seems like an Ubuntu thing that was not ever suggested to use in debian. If you want to stay on bleeding edge for packages, the suggestion would be to use debian sid. I'm not sure what you mean 30 GB of memory. How is that related? And how would merging the -dev packages into the library packages solve it? IMO there are problems with the Debian approach but I wouldn't say that's one of them -- a worse problem to me is that things like cross-compiling/multi-arch mostly requires chrooting which is a lot less convenient than the approach used by something like Nix.

andrewshadura 5y ago
You don't need to chroot for cross-compiling, Debian supports multi-arch for most of the packages. You just install the cross-compiler, the cross-libc and all native development packages for the architecture you're building for.
- zxzax 5y ago
  Last time I tried that I had bad problems with package conflicts trying to overwrite files, but it was a while ago and maybe I was doing something wrong, I'll give it another shot.

viraptor 5y ago

> As long as Debian separates between distributed binaries, and -dev packages which include all source codes and headers - I would not recommend it for software development. Is that the case for some specific languages? -dev packages for C and other compiled libraries do not include the full source code of the library. Normally they only include the headers, pkgconfig, and similar files. > Libraries are not upgradeable due to how other packages depend on them. Got some examples where it's a problem and not an actual dependency issue?

cookiengineer 5y ago
> Got some examples where it's a problem and not an actual dependency issue? Try to recompile mesa or say, just the demos (aka glxgears) :) Worst case scenario for Debian dependencies.
- viraptor 5y ago
  I meant an example of what the issue is. Glxgears seems to have reasonable dependencies (https://packages.debian.org/buster/mesa-utils https://packages.debian.org/buster/mesa-utils) gl1 and glu1 are not even restricted on versions.
- seba_dos1 5y ago
  I regularly recompile mesa on my Debian-based phone and I'm not exactly sure what you mean. It goes painless.

tinus_hn 5y ago

So you would rather have them waste that exact same amount of space on every computer, just so you don’t have to download it when you want to build a package?

creshal 5y ago
I don't have any Debian machine that doesn't end up with build-essential and dozens of header packages installed; it just comes up too often. Adding the header files directly to the packages saves time and frustration, and probably even saves space since a lot these packages are 50% overhead (dpkg meta files, db entries, etc.) by size.
- tinus_hn 5y ago
  I refuse to believe that these meta files and database entries are occupying anywhere near a relevant amount of space.
  - creshal 5y ago
    Relatively. Absolutely, it's negligible - because the space consumption of header files is also negligible. It's such a bizarre design choice to split out a single 30 line .h file into a separate package.
- _d7dt 5y ago
  I don't install build-essential on a server, in a container, on a VM, etc. It really matters in those places. If you combine them then you lose the ability to deploy a small rootfs.
  - creshal 5y ago
    Servers, VMs etc. always end up getting build-essential to handle random python/ruby/npm/... package installations, as the shipped versions are hopelessly outdated and creating your own debian packages for all of them is about as enjoyable as performing appendix surgery on yourself. Multi-stage builds do make it a bit easier to get rid of them for containers, yes, but during the build stage it's still required.