search

omniosorg / pkg5

Image Packaging System
https://omnios.org/
Other
12 stars 56 forks source link

installation in a sparse-zone can 'succeed' when a package has files in a shared filesystem #401

Closed mounty1 closed 2 years ago

mounty1 commented 2 years ago

An example is isc-dhcp, which has /usr/sbin/dhcpd. If this package be installed in a sparse zone, then pkg install reports no error, but /usr/sbin/dhcpd is not installed because filesystem /usr is shared and read-only in the zone.

At the very least, pkg install should emit a warning for the omitted file, but really, pkg install should fail because the package has not been installed.

mounty1 commented 2 years ago

I don't understand the logic of pkg install succeeding when the package has not been installed. It seems to me that the warning should apply only in the presence of an enabling command-line flag and that the default action should be to fail.

citrus-it commented 2 years ago

I don't understand the logic of pkg install succeeding when the package has not been installed. It seems to me that the warning should apply only in the presence of an enabling command-line flag and that the default action should be to fail.

In a partial image, it's just that /some/ of the actions have not been installed. For example I have some zones where I mount /var/log on a separate cross-BE dataset, and there I deliberately exclude /var/log/pkg since otherwise a new-BE upgrade will create the directory. On reboot. the ZFS mount will fail and services won't come online. Exclusions are a generic feature of IPS which just happen to be used for sparse zones.

In addition to this type of usage, there are a couple of other widely used patterns:

  1. Installing a package into a sparse zone when the package is already installed in the global zone: In this case, the package ends up marked as installed and any files which are not in the shared directories get delivered, for example configuration files under /etc.

  2. Installing a package which delivers most of its content to somewhere like /opt: gcc is a good example of this, where the content in /usr are just links to /opt.

Whilst these could require something like --force, I think that things like this are common enough that they are probably in some shell scripts and we'd end up breaking them.

mounty1 commented 2 years ago

Concerning the cases above:

  1. If the file is in /usr for example by the package having been installed in the global zone then that counts as installed, provided the file has the same content and ownership. That's "installed by already being there".
  2. If the links aren't necessary, why are they in the package? That's maybe a case for a file being marked "nice to have" or "not required for successful installation" but that's an unusual case.

If shell scripts are relying on packages being installed when they are not, then the shell scripts are already broken. That argument gives excessive weight to backward compatibility.

I don't see any point in continuing just to argue this back and forth. I've said my piece and it's now up to the maintainers of OmniOS to decide what to do with this this issue.

citrus-it commented 2 years ago

If shell scripts are relying on packages being installed when they are not, then the shell scripts are already broken.

I think at this point it's a matter of semantics. The packages are installed, just some of their actions may have been elided due to the image configuration. There was a suggestion posted on the pull request associated with this issue that we introduce a new image property to control the behaviour, which allows flexibility. I've gone ahead and updated the pull request with that. For sparse zones, the default behaviour will be to reject the operations.