How we're handling packages that collide with z/OS UNIX tools under /bin/

[IgorTodorovskiIBM]

Package Collisions with z/OS UNIX tools

In short, the z/OS /bin tools will now take precedence over z/OS Open Tools of the same name. If you want the z/OS Open Tools to take precedence, source your zopen configuration as follows:

. <zopen_root>/etc/zopen-config --override-zos-tools

Make sure to update meta first, zopen upgrade meta -y

Packages such as coreutils, gawk, sed, findutils, grep, diffutils, man-db, iconv and openssh provide executables that conflict with the z/OS UNIX tools under /bin. Some of these packages differ in behaviour.

If you prefer to use the tools without the prefix (as before), follow Using Tools without Prefix below

Prefixing for z/OS Open Tools

To ensure seamless interaction with z/OS tools under /bin, z/OS Open tools that collide with a z/OS UNIX tool under <package>/bin will be prefixed as follows:

• g prefix for GNU-based tools (Coreutils, Awk, Findutils, Diffutils, Grep, Sed) . E.g., gmake and gawk.
• zot prefix for non-GNU-based tools (Man-db, OpenSSH). E.g., zotssh and zotman - Note we avoided using z prefix since it is used in z/OS tools like zlsof

Tools that have collisions will also print out an install caveat during zopen install.

The original unprefixed binaries will be placed under <package>/altbin.

Using Tools without Prefix

If you prefer to use the tools without the prefix, you can specify the --override-zos-tools option when sourcing zopen-config as follows:

. <zopen_root>/etc/zopen-config --override-zos-tools

Alternatively, you can add $ZOPEN_ROOTFS/usr/local/altbin to your $PATH.

This is documented under https://zosopentools.org/#/Guides/ThePackageManager?id=package-collisions-with-zos-unix-tools

Any questions or concerns? add a comment here

[IgorTodorovskiIBM]

Note: we are still in the process of updating man-db and coreutils and iconv

[MikeFultonDev]

I love zot...

[IgorTodorovskiIBM]

The current option --override-zos-tools is an all or nothing option. We have an issue open for selecting which tools to override #815

[lbdyck]

I have to disagree with this approach - it has already broken a few of my tools and usage and having to communicate this to various users could be problematic. My $0.01

[IgorTodorovskiIBM]

We wanted to provide flexibility for users so that they can maintain a single shared copy of the zopen filesystem while also providing individual consumers the ability to choose if they want the z/OS UNIX tools vs z/OS Open Tools to take precedence in the case of collisions. Some packages like findutils and coreutils have partial collisions. So the solution was to separate the executables that collide from bin to altbin.
Many existing clients have preexisting scripts that don’t have absolute paths in their scripts, and just the command name. They’d rather z/OS UNIX /bin tools take precedence by default so that they dont have to go in and change each of their scripts.

The --override-zos-tools option adds altbin plus bin to the PATH which will match the previous behaviour.

We have had complaints from users who are picking up z/OS Open Tools for the first time and having the GNU tools break their builds, which is why we went with this approach. We can certainly make --override-zos-tools the default - we could put it up for a vote.

[IgorTodorovskiIBM]

One example - zopencommunity/opensshport#10 (comment)
Another example is ZOAU which assumed awk from /bin and adding z/OS Open Tools gawk broke the existing scripts - zopencommunity/gawkport#23
Also numerous examples within IBM - many scripts are still assuming make/sed/awk from /bin vs GNU tools.

Question is which default makes more sense. I dont mind changing it to --nooverride-zos-tools since the behaviour will not b a surprise to the user. @MikeFultonDev, @AnthonyGiorgio, @DevonianTeuchter, @HarithaIBM, @gngrossi any thoughts?

[DevonianTeuchter]

My 2c: having the default be the "native" /bin tooling probably makes sense. It will only be early adopters who have the zot tools first and updated their scripts etc. and are likely more aware of the nuances of the different versions and have the technical know-how to understand and resolve the issue. As more, less-zot-aware users come on board, legacy scripts (and knowledge!) will be prone to breakage - and possibly with unexpected/unusual/confusing error messages.

[lbdyck]

i like your 2c

[IgorTodorovskiIBM]

Another option that would satisfy both parties is to have a zopen configuration option that configures the default behaviour for the zopen filesystem. --set override-zos-tools true - this would be a one time setting by the zopen admin and then users can continue to source zopen-config as before. And the zopen-config option would flip from override-zos-tools to nooverride-zos-tools. This way the zopen admin dictates the default

[gngrossi]

I echo the having the default be native the /bin tools. If feasible, it would be good to provide a global config file as input to the
--override-zos-tools option. Also, maybe provide a user version of the global file (in $HOME as a hidden file) to override the global.