Allow multiple icommands versions to be installed

[kript]

We often find ourselves in the situation where we run one version of iRODS in production, and another in test. Currently only one version of the icommands can be installed at a time, and since run-in-place is no longer supported or production, we can't build them ourselves and place in, say /opt/renci/4.2.7 etc...

It would be very helpful if the icommands could be installed in a way that is version specific, e.g. /usr/bin/icommands_4.1.12/ils, /usr/bin/icommands_4.2.7/ils (or even preferably /opt/renci/4.2.7/ )etc, and have a way in one's irods_environemnt.json file to set the version required (with, say, the latest being the default).

This is probably related to irods/irods_client_icommands#66

Thank you!

[mcv21]

On .deb-based systems, an approach based on update-alternatives would probably be the way to go

[mcast]

The need for this comes partly from our code, which needs to reach into different zones that may be on separate upgrade schedules.

An extra factor is the need for irods_environment.json > "irods_plugins_home" which we needed on old Ubuntu Precise with icommands in /opt/renci. This became incompatible at the user config file level with new Ubuntu Bionic icommands in /usr/bin.

As we have users who may run the commands from either OS with a shared homedir, and would prefer not to have another level of "which OS are we on? need to grab different config files!", it makes a window of time without a well-defined cutover date.

(Hoping this made sense - happy to clarify)

[kript]

Talking to other internal users, they would need to be able do an equivalent of ./configure --prefix=/opt && make && make install. If it were possible to build the iRODS client libraries and install them and the headers to /opt or /usr/local that should be enough.

This would be for building baton and samtools, as well as for building variable location icommands.

[alanking]

I believe the effort by @SwooshyCueb to provide the userspace tarball packaging option in the iCommands takes care of this? See #5082 and https://github.com/irods/irods_client_icommands/?tab=readme-ov-file#userspace-packaging

[SwooshyCueb]

I'm not sure I'm understanding what's being asked for here. I see mentions of headers, which are not part of the userspace tarball packages.

The tarball packager almost certainly needs some updating at this point, though.

[alanking]

Okay. I'm going to bump this out since I don't think it is critical for anybody at the moment and sat dormant for over 4 years.

[kript]

It's still very much a 'nice to have'. We've worked around it for now by using Singularity containers running the icommands but where this gets tricky is for clients built on top of the headers, e.g. baton.

Things have improved now the irods-devel, irods-runtime and irods-icommands are separate packages (however this still doesn't allow us to have two versions installed), but there is still the need, overall, to have at least two versions of icommands -one for production and one for testing the next version.

Hope that helps clarify,

John

[trel]

Yes, sounds like non-package install is still the easiest thing here.

update-alternatives is interesting, but seems ... fraught.

[mcv21]

update-alertnatives is quite nice really - you get to set a sensible default amongst alternatives, and then the sysadmin can override if they see fit.

[trel]

is there an rpm-world equivalent?

[mcv21]

I think there is update-alertnatives available for rpm-based systems (RPMFind has hits, and there's SLES documentation), although I don't work with any rpm-based distros any more.