Why did MacOS develop its own package manager?

• Keg only installation vs system installation (so that it doesn't overlay system tools)
• Brew wanted to use ruby because it was already part of MacOS
• They wanted contributions from the community - It uses github for everything, including formulae

Pros and Cons of z/OS having its own package manager

DNF5

• Updates:
  dnf5 has landed in Fedora 41
  Lots of interesting & relevant info here - Changes in Fedora 41 For System Administrators
  Specifically:
  rpm 4.20 - declarative build system, public plugin API, per-build directory
  Reproducible package builds

• built around rpm

• (traditionally) required root privs and affects system libraries - could affect pre-installed software

Links for reference:
Owners are RedHat employees - https://fedoraproject.org/wiki/Changes/SwitchToDnf5#Owner
Announcement & discussion thread - https://fedoraproject.org/wiki/Changes/SwitchToDnf5#Current_status
readthedocs - https://dnf5.readthedocs.io/en/latest/index.html

Conference talks: (worth watching)
DNF5 - Next Generation of Software Management - DevConf.CZ 2023
openSUSE Conference 2023 - The Geeko View on DNF 5

First step may be to port rpm - https://github.com/rpm-software-management/rpm
rpm​ probably needed to allow offline installs from .rpm​ files
dnf5 is higher level - https://github.com/rpm-software-management/dnf5

On root/elevation:
Because we're porting, we can swap the code that checks if the command is being run as uid 0, to make it check for some other pre-determined uid/gid instead.
At the zOS level, we can decide that uid:gid 9991:9999 is a special combo, and is to be used on the RACF user/group which we want to consider sudo.
Then, with a combo of sudoers and RACF groups, and general RACF profiles/classes, we should be able to figure something out... like some route to elevated access.

Because we have overlayfs now, another option is to write into overlays instead.
We can't do exactly what's described below, but can use it for inspiration -
https://docs.fedoraproject.org/en-US/bootc/dnf/#_using_dnf_at_runtime
https://www.freedesktop.org/software/systemd/man/latest/systemd-sysext.html

On datasets:
Feeling confident that the combo of libdio/asmdio is sufficient to allow rpm/dnf5 to write/install into datasets.
This means *dio either needs to go into upstream rpm/dnf, or we simply add it as a pre-req to rpm/dnf and eventually make it a part of OEF.

Advantages:

• Relies on decades of development & improvements
• spec language is improving constantly
• --installroot​ can be used to install in non-system locations
• Dependency mgmt
• group install
• allows wider adoption of zopen via repo mgrs' existing support for yum/dnf
• can add plugins
• RedHat skills are available within IBM now
• Switch to industry standard naming:
  • 31-bit - zstd-1.5.5-4.zos24.s390.{pax.zst,pax.Z,rpm}​
  • 64-bit - zstd-1.5.5-4.zos24.s390x.{pax.zst,pax.Z,rpm}​

Disadvantages:

• May not be a quick task
• Need to refactor zopen (meta) to limit its scope to being a build tool