4 ms·

I really do wonder how often this happens. Like, I know that Python is particularly prone to this, and if you have multiple languages needing C/C++ based libra

I really do wonder how often this happens. Like, I know that Python is particularly prone to this, and if you have multiple languages needing C/C++ based libraries then I guess this is a concern. But how many people have experienced this to an extent that containerisation seems like the right solution most of the time?

AnHonestComment 6y ago
Why wouldn’t containerization be the right solution? A “container” is an archive (eg, tarballs) of the contents, a hash chain of the construction, and some config data about cgroups and namespaces to run it with. Turn off the parts you don’t want — I usually turn off virtualized networking, for instance. It’s a more lightweight package that doesn’t have versioning problems and doesn’t require crazy installation scripts — what benefit is traditional Debian packaging supposed to have?
closeparen 6y ago
I’m convinced that the real reason is all the cruft in packaging systems and opinions among their domain experts that are specific to the needs of distro maintainers. “Docker Build” could produce DEB packages as a target and they would be fine 99% of the time.
- rleigh 6y ago
  They wouldn't. There's far more to a Debian package than simply aggregating a bunch of files into a container and calling it a day. Making sure it's all correctly split into runtime, library, development, documentation, debug etc. parts, and ensuring that each part has the correct dependencies upon other packages in the system is a much more involved task. But it's this part that adds most of the value compared with simply building from source. Making a "package" is easy. But the real point of packaging is integration with the wider system, and that part requires actual effort. Docker doesn't even attempt it. Docker is easy and convenient primarily because it pretends that problem doesn't even exist. It does the easy 10% of the job while ignoring the 90% of the work that takes the time and effort.
  - closeparen 6y ago
    This might be a misunderstanding... they would be fine in 99% of the cases where containers are currently used, not where packages are currently used.

AnHonestComment 6y ago

Why wouldn’t containerization be the right solution? A “container” is an archive (eg, tarballs) of the contents, a hash chain of the construction, and some config data about cgroups and namespaces to run it with. Turn off the parts you don’t want — I usually turn off virtualized networking, for instance. It’s a more lightweight package that doesn’t have versioning problems and doesn’t require crazy installation scripts — what benefit is traditional Debian packaging supposed to have?

closeparen 6y ago

I’m convinced that the real reason is all the cruft in packaging systems and opinions among their domain experts that are specific to the needs of distro maintainers. “Docker Build” could produce DEB packages as a target and they would be fine 99% of the time.

rleigh 6y ago
They wouldn't. There's far more to a Debian package than simply aggregating a bunch of files into a container and calling it a day. Making sure it's all correctly split into runtime, library, development, documentation, debug etc. parts, and ensuring that each part has the correct dependencies upon other packages in the system is a much more involved task. But it's this part that adds most of the value compared with simply building from source. Making a "package" is easy. But the real point of packaging is integration with the wider system, and that part requires actual effort. Docker doesn't even attempt it. Docker is easy and convenient primarily because it pretends that problem doesn't even exist. It does the easy 10% of the job while ignoring the 90% of the work that takes the time and effort.
- closeparen 6y ago
  This might be a misunderstanding... they would be fine in 99% of the cases where containers are currently used, not where packages are currently used.