4 ms·

How do Debian packages isolate ? Can you make sure that e.g. app1 won't replace app2's config file with its own (if, say, both app1 and app2 need ImageMagick wi

How do Debian packages isolate ? Can you make sure that e.g. app1 won't replace app2's config file with its own (if, say, both app1 and app2 need ImageMagick with different policies) ?

disgruntledphd2 6y ago
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.
deleted 6y ago
[deleted]
curryst 6y ago
I believe those changes are tracked, there are commands that will tell you what package a file is from (I think it might be apt-file). It's been a while since I used apt in depth, but I do know that pacman tracks that and will log error messages if a file already exists. For example when config formats change, if I have /etc/example.yml created already, pacman will throw an error and put the new file at /etc/example.yml.pac-new (or a similar scheme). > (if, say, both app1 and app2 need ImageMagick with different policies) ? Debian typically handles that by building fat binaries/libraries with all the possible options enabled. In cases where there are multiple incompatible options, I'm not an expert, but I believe you create a virtual/meta "package" that can be satisfied by installation of any of the incompatible binaries. Pacman handles it similarly. Gentoo is an oddball in that it tracks a set of system flags and enabled/disables features in builds based on which flags you have set. It's able to do that because it compiles the packages itself, so you can choose the options at install time.
- jcelerier 6y ago
  > For example when config formats change, if I have /etc/example.yml created already, pacman will throw an error and put the new file at /etc/example.yml.pac-new But, you understand that this means that Debian doesn't handle the issue, right ? Like, cool, I got an error but I still can't make my two programs run concurrently, back to Docker it is. Also some programs may generate config files or stuff in /var at runtime so apt can't even warn.
rleigh 6y ago
Err, because it's the job of the package manager to prevent this exact situation from happening... Packages are not permitted to overwrite data files or configuration files (conffiles) from other packages. dpkg would abort the installation or upgrade of any package which tried to usurp a file owned by another package. At least, not without an explicit Replaces dependency to allow adoption of them. Enforcing consistency and ownership with a central database is the entire point of managing the system with a package manager. This isn't even new. This is 25+ year old technology at this point.
- jcelerier 6y ago
  Yes, and this is a behaviour that prevents various use cases, hence we need different tools with better isolation, hence docker. > Enforcing consistency and ownership with a central database is Assuming a lot of things very wrongly. My distro maintainer's idea of consistency may be very different from mine - it's not the system that matters, it's the freakin apps because running this is the only reason we buy computers for, and it happens that you need to run two apps which would be entirely incompatible on the same system (if I take my past life music production experience, for instance you really really want to keep using the same version of a software for a given project. But you can have a dozen different projects in flight which all require different versions of the software used. Try installing 12 different versions of gimp or ardour on Linux without something like appimage :))

How do Debian packages isolate ? Can you make sure that e.g. app1 won't replace app2's config file with its own (if, say, both app1 and app2 need ImageMagick with different policies) ?

disgruntledphd2 6y ago

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.

deleted 6y ago

[deleted]

curryst 6y ago

I believe those changes are tracked, there are commands that will tell you what package a file is from (I think it might be apt-file). It's been a while since I used apt in depth, but I do know that pacman tracks that and will log error messages if a file already exists. For example when config formats change, if I have /etc/example.yml created already, pacman will throw an error and put the new file at /etc/example.yml.pac-new (or a similar scheme). > (if, say, both app1 and app2 need ImageMagick with different policies) ? Debian typically handles that by building fat binaries/libraries with all the possible options enabled. In cases where there are multiple incompatible options, I'm not an expert, but I believe you create a virtual/meta "package" that can be satisfied by installation of any of the incompatible binaries. Pacman handles it similarly. Gentoo is an oddball in that it tracks a set of system flags and enabled/disables features in builds based on which flags you have set. It's able to do that because it compiles the packages itself, so you can choose the options at install time.

jcelerier 6y ago
> For example when config formats change, if I have /etc/example.yml created already, pacman will throw an error and put the new file at /etc/example.yml.pac-new But, you understand that this means that Debian doesn't handle the issue, right ? Like, cool, I got an error but I still can't make my two programs run concurrently, back to Docker it is. Also some programs may generate config files or stuff in /var at runtime so apt can't even warn.

rleigh 6y ago

Err, because it's the job of the package manager to prevent this exact situation from happening... Packages are not permitted to overwrite data files or configuration files (conffiles) from other packages. dpkg would abort the installation or upgrade of any package which tried to usurp a file owned by another package. At least, not without an explicit Replaces dependency to allow adoption of them. Enforcing consistency and ownership with a central database is the entire point of managing the system with a package manager. This isn't even new. This is 25+ year old technology at this point.

jcelerier 6y ago
Yes, and this is a behaviour that prevents various use cases, hence we need different tools with better isolation, hence docker. > Enforcing consistency and ownership with a central database is Assuming a lot of things very wrongly. My distro maintainer's idea of consistency may be very different from mine - it's not the system that matters, it's the freakin apps because running this is the only reason we buy computers for, and it happens that you need to run two apps which would be entirely incompatible on the same system (if I take my past life music production experience, for instance you really really want to keep using the same version of a software for a given project. But you can have a dozen different projects in flight which all require different versions of the software used. Try installing 12 different versions of gimp or ardour on Linux without something like appimage :))