5 ms·

> everyday Linux desperately needs a proper application management You mean something, that won't allow two packages to own the same file? Something, like, rpm

> everyday Linux desperately needs a proper application management You mean something, that won't allow two packages to own the same file? Something, like, rpm or apt?

y4mi 9y ago
You probably meant rpm and dpkg... Or you'd have to compare yum, zypper, apt, pacman and whatever else is out there. But, I'm certain the parent didn't mean that. Dpkg and rpm both allow packages to overwrite files from each other and, more dangerously, allow fully authorized post-install scripts. And they're often necessary for sane package management (create user, initiate database), but could be exploited to wreck havoc on the system.
- vetinari 9y ago
  Yes, I meant dpkg. Not sure about dpkg, but rpm does not allow two packages to own the same file. If you try to install package, that contains file owned by another, already installed package, the installation will fail (you can try that with installing an amd64 package that owns something in /usr/share, and then try to install the i386 version). Yes, post-install scripts are dangerous and rpm folks are doing small steps to phase them out: https://www.youtube.com/watch?v=kE-8ZRISFqA https://www.youtube.com/watch?v=kE-8ZRISFqA
  - Piskvorrr 9y ago
    dpkg will throw a fit in the same way.
    - y4mi 9y ago
      it will throw an error message, which the user is probably going to ignore and install anyway. This will ultimately cause errors down the line. Maybe not right now, but eventually problems will occur. showing a warning is great, but not needing that warning would be preferable. but most distributions are already working on solutions to that. ubuntu is working on SnapOn's [0] for example, and i remember hearing about something else from redhad as well. [0] https://snapcraft.io/ https://snapcraft.io/
      - __david__ 9y ago
        No, it will not install the package at all: $ mkdir root/bin/ $ (echo '#!/bin/sh'; echo 'echo "hi"') > root/bin/ls $ chmod +x root/bin/ls $ fpm -s dir -t deb -n bad-ls -v 1.0 -C `pwd`/root . Created package {:path=>"bad-ls_1.0_amd64.deb"} $ dpkg-deb -c bad-ls_1.0_amd64.deb drwxrwxr-x 0/0 0 2018-02-22 10:44 ./ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/share/ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/share/doc/ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/share/doc/bad-ls/ -rw-r--r-- 0/0 142 2018-02-22 10:44 ./usr/share/doc/bad-ls/changelog.gz drwxrwxr-x 0/0 0 2018-02-22 10:44 ./bin/ -rwxrwxr-x 0/0 20 2018-02-22 10:42 ./bin/ls $ sudo dpkg -i bad-ls_1.0_amd64.deb Selecting previously unselected package bad-ls. (Reading database ... 837129 files and directories currently installed.) Preparing to unpack bad-ls_1.0_amd64.deb ... Unpacking bad-ls (1.0) ... dpkg: error processing archive bad-ls_1.0_amd64.deb (--install): trying to overwrite '/bin/ls', which is also in package coreutils 8.28-1 Errors were encountered while processing: bad-ls_1.0_amd64.deb $ ls -l /bin/ls -rwxr-xr-x 1 root root 134792 Oct 2 10:51 /bin/ls* It doesn't just warn and leave things in a bad state.
        y4mi 9y ago
        this is strange. I encountered a conflict at work recently with an /etc/ file conflict. the stdout of the dpkg errormsg gave me the required tag i could use to do it anyway. it was basically just !! double click -> middle click
      - Piskvorrr 9y ago
        Actually, it will throw an error - on which the higher-level (libapt) tools above dpkg will abort, and going directly to dpkg with a --force-whatever is not quite as easy as clicking "yeah, just do it already". Not to mention that I have needed that twice in a decade, in rather obscure cases. But yeah, containerizing the apps is probably a way forward, which sidesteps whole classes of issues.
- pm215 9y ago
  dpkg won't allow one package to overwrite a file from another unless you pass it --force-overwrite, which is not the default.
Silhouette 9y ago
You mean something, that won't allow two packages to own the same file? Something, like, rpm or apt? No, not really. For one thing, package managers are only useful on packages supplied by the distro (or otherwise bundled using that convention), and we need something that allows for installing (and uninstalling, and backing up configurations for, and...) software safely and systematically in the general case. For another thing, even packages installed with a distro's own package manager can typically dump whatever files they want wherever they want, rather than having the OS restrict them to a controlled environment.
- vetinari 9y ago
  > For one thing, package managers are only useful on packages supplied by the distro (or otherwise bundled using that convention), and we need something that allows for installing (and uninstalling, and backing up configurations for, and...) software safely and systematically in the general case. There's nothing that limits rpm/deb to distribution. Anyone who publishes a tarball with software, can publish rpm/deb as well. Many do. > For another thing, even packages installed with a distro's own package manager can typically dump whatever files they want wherever they want, rather than having the OS restrict them to a controlled environment. The list of files in manifest is checked beforehand and if there's a conflict with existing package, the installation is aborted.
  - Silhouette 9y ago
    There's nothing that limits rpm/deb to distribution. Anyone who publishes a tarball with software, can publish rpm/deb as well. Many do. Hence my "or otherwise bundled..." note. But you're still only thinking in terms of packages that are bundled and installed via the system tool. Anything not installed via that tool can typically do whatever it wants if its scripts run as root, and anything that is installed via that tool typically won't be aware of anything that wasn't and will happily write all over it with no mechanism for backing up what was there before or reverting a breaking change. The point is that relying on some voluntary convention like this isn't good enough. A modern OS should enforce mandatory restrictions on all installed software. We should be able to do things like checking exactly what is installed, or uninstalling something unwanted with or without also uninstalling any now-unused dependencies or any configuration data, and we should be able to do these things reliably, safely, and without any requirement for the software itself to be "well behaved" in any particular way.

> everyday Linux desperately needs a proper application management You mean something, that won't allow two packages to own the same file? Something, like, rpm or apt?

y4mi 9y ago

You probably meant rpm and dpkg... Or you'd have to compare yum, zypper, apt, pacman and whatever else is out there. But, I'm certain the parent didn't mean that. Dpkg and rpm both allow packages to overwrite files from each other and, more dangerously, allow fully authorized post-install scripts. And they're often necessary for sane package management (create user, initiate database), but could be exploited to wreck havoc on the system.

vetinari 9y ago
Yes, I meant dpkg. Not sure about dpkg, but rpm does not allow two packages to own the same file. If you try to install package, that contains file owned by another, already installed package, the installation will fail (you can try that with installing an amd64 package that owns something in /usr/share, and then try to install the i386 version). Yes, post-install scripts are dangerous and rpm folks are doing small steps to phase them out: https://www.youtube.com/watch?v=kE-8ZRISFqA https://www.youtube.com/watch?v=kE-8ZRISFqA
- Piskvorrr 9y ago
  dpkg will throw a fit in the same way.
  - y4mi 9y ago
    it will throw an error message, which the user is probably going to ignore and install anyway. This will ultimately cause errors down the line. Maybe not right now, but eventually problems will occur. showing a warning is great, but not needing that warning would be preferable. but most distributions are already working on solutions to that. ubuntu is working on SnapOn's [0] for example, and i remember hearing about something else from redhad as well. [0] https://snapcraft.io/ https://snapcraft.io/
    - __david__ 9y ago
      No, it will not install the package at all: $ mkdir root/bin/ $ (echo '#!/bin/sh'; echo 'echo "hi"') > root/bin/ls $ chmod +x root/bin/ls $ fpm -s dir -t deb -n bad-ls -v 1.0 -C `pwd`/root . Created package {:path=>"bad-ls_1.0_amd64.deb"} $ dpkg-deb -c bad-ls_1.0_amd64.deb drwxrwxr-x 0/0 0 2018-02-22 10:44 ./ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/share/ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/share/doc/ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/share/doc/bad-ls/ -rw-r--r-- 0/0 142 2018-02-22 10:44 ./usr/share/doc/bad-ls/changelog.gz drwxrwxr-x 0/0 0 2018-02-22 10:44 ./bin/ -rwxrwxr-x 0/0 20 2018-02-22 10:42 ./bin/ls $ sudo dpkg -i bad-ls_1.0_amd64.deb Selecting previously unselected package bad-ls. (Reading database ... 837129 files and directories currently installed.) Preparing to unpack bad-ls_1.0_amd64.deb ... Unpacking bad-ls (1.0) ... dpkg: error processing archive bad-ls_1.0_amd64.deb (--install): trying to overwrite '/bin/ls', which is also in package coreutils 8.28-1 Errors were encountered while processing: bad-ls_1.0_amd64.deb $ ls -l /bin/ls -rwxr-xr-x 1 root root 134792 Oct 2 10:51 /bin/ls* It doesn't just warn and leave things in a bad state.
      - y4mi 9y ago
        this is strange. I encountered a conflict at work recently with an /etc/ file conflict. the stdout of the dpkg errormsg gave me the required tag i could use to do it anyway. it was basically just !! double click -> middle click
    - Piskvorrr 9y ago
      Actually, it will throw an error - on which the higher-level (libapt) tools above dpkg will abort, and going directly to dpkg with a --force-whatever is not quite as easy as clicking "yeah, just do it already". Not to mention that I have needed that twice in a decade, in rather obscure cases. But yeah, containerizing the apps is probably a way forward, which sidesteps whole classes of issues.
pm215 9y ago
dpkg won't allow one package to overwrite a file from another unless you pass it --force-overwrite, which is not the default.

Silhouette 9y ago

You mean something, that won't allow two packages to own the same file? Something, like, rpm or apt? No, not really. For one thing, package managers are only useful on packages supplied by the distro (or otherwise bundled using that convention), and we need something that allows for installing (and uninstalling, and backing up configurations for, and...) software safely and systematically in the general case. For another thing, even packages installed with a distro's own package manager can typically dump whatever files they want wherever they want, rather than having the OS restrict them to a controlled environment.

vetinari 9y ago
> For one thing, package managers are only useful on packages supplied by the distro (or otherwise bundled using that convention), and we need something that allows for installing (and uninstalling, and backing up configurations for, and...) software safely and systematically in the general case. There's nothing that limits rpm/deb to distribution. Anyone who publishes a tarball with software, can publish rpm/deb as well. Many do. > For another thing, even packages installed with a distro's own package manager can typically dump whatever files they want wherever they want, rather than having the OS restrict them to a controlled environment. The list of files in manifest is checked beforehand and if there's a conflict with existing package, the installation is aborted.
- Silhouette 9y ago
  There's nothing that limits rpm/deb to distribution. Anyone who publishes a tarball with software, can publish rpm/deb as well. Many do. Hence my "or otherwise bundled..." note. But you're still only thinking in terms of packages that are bundled and installed via the system tool. Anything not installed via that tool can typically do whatever it wants if its scripts run as root, and anything that is installed via that tool typically won't be aware of anything that wasn't and will happily write all over it with no mechanism for backing up what was there before or reverting a breaking change. The point is that relying on some voluntary convention like this isn't good enough. A modern OS should enforce mandatory restrictions on all installed software. We should be able to do things like checking exactly what is installed, or uninstalling something unwanted with or without also uninstalling any now-unused dependencies or any configuration data, and we should be able to do these things reliably, safely, and without any requirement for the software itself to be "well behaved" in any particular way.