Install rascsi in the Linux standard software package path, i.e. in /opt

[uweseimet]

The Linux standard software installation path is /opt, just like for (other) SVR4 platforms. rascsi binaries should be installed in /opt/rascsi/bin, the manpages in /opt/rascsi/man. When changing the installation path to /opt (in the Makefile), old installations in /usr/local/bin should be removed (rm -f). Of course, only the rascsi-related binaries should be removed, not everything in /usr/local/bin.
easyinstall also has to be changed, because the systemd service needs to use the new path /opt/rascsi/bin/rascsi to start rascsi.

The easyinstall should suggest to add /opt/rascsi/bin to $PATH and /opt/rascsi/man to $MANPATH. This is not mandatory, but useful if a user wants to start rascsi manually.

[akuker]

The easyinstall should suggest to add /opt/rascsi/bin to $PATH and /opt/rascsi/man to $MANPATH. This is not mandatory, but useful if a user wants to start rascsi manually.

I think adding /opt/rascsi/bin to the $PATH would be mandatory. I still use the rasctl utility often. Maybe I'm the only person who does this, but I think the utility should be on the PATH when rascsi gets installed.

After spending a while diving down this rabbit hole, it doesn't appear that there is a clear-cut right and wrong approach to this.

https://unix.stackexchange.com/questions/11544/what-is-the-difference-between-opt-and-usr-local

Since we currently have a rascsi disk image, it could be argued that rascsi is now part of this distribution, and therefore fits in /usr/local instead of /opt

I'm going to tag this issue as an enhancement, since I don't view the current file placement as a defect. From my initial evaluation, it seems like the risks outweigh the benefits. Please let me know if I'm missing anything here:

Benefits:

• Easier to delete/uninstall rascsi
• Slightly better consistency with SVR4 (this point may be debatable)

Risks

• Need to modify the $PATH variable
• Potential for breaking things

In summary: I'm not saying we shouldn't do this... I just want to understand the benefits more.

[uweseimet]

@akuker I also see pros and cons here. But if each software installation would just throw everything into /usr/local/bin, like rascsi does it, this would be quite a mess.

[funkyfuture]

But if each software installation would just throw everything into /usr/local/bin, like rascsi does it, this would be quite a mess.

but that is what every installation does (respectively in /usr/bin). that is usually no problem when there are complementing install and uninstall routines.

but i wonder whether there are devices that run more applications than just rascsi. if not, what i assume, the question about messiness just doesn't apply.

as context: i'm currently looking at this repo b/c i'm interested in using rascsi. am i understanding correctly that there are neither deb-packages or filesystem images (i know one can buy these), but the setup (and subsequent updates) is quiet a manual process?

[uweseimet]

@funkyfuture Regarding the usage of /opt it is not correct that every software installation on Linux uses /usr/local/bin. /opt is a convention for software package installations introduced long ago with System V, and it helps keeping packages separated and structured, which is a good thing. On my gentoo system, for instance, the package manager installs java, skype, firefox, spotify and other packages in /opt. It is not uncommon that /opt is a separate filesystem, exported via nfs, in order to share installations between different machines.
The assumption that users of rascsi do no install anything else on their Pi may be correct in your case, but is it correct for everybody?

[akuker]

am i understanding correctly that there are neither deb-packages or filesystem images (i know one can buy these), but the setup (and subsequent updates) is quiet a manual process?

You are partially correct. There is no deb package available for RaSCSI. There is an "easyinstall.sh" tool that will install/configure RaSCSI for you. That has been our answer to the deb package need. (A future deb package is not out of the question though)

There is also a pre-built image that is available (for free) that you can download. For the last few software releases, there are Raspberry Pi OS Lite images available that have RaSCSI pre-configured. For example: https://github.com/akuker/RASCSI/releases/tag/v22.02.01 (Zip file is at the bottom of the page)

[funkyfuture]

thank you for your feedbacks.

the Linux FHS is very clear that there is not the one location where software is to be installed. if it was to be kept within one branch of the filesystem, yes, that'd be in /opt.

would an issue or even a preliminary pr that aims to create deb packages be of interest for you?

[uweseimet]

@funkyfuture Personally I think that it would be good to have debian packages with rascsi binaries. These items should IMO be considered, though:

• All library dependencies should be covered, i.e. when installing the package all dependencies should also be installed. I guess this is part of the package definition.
• How does the user configure rascsi, e.g. the systemd setup? I'm not familiar with creating debian packages, but I assume this is covered somehow?
• Creating the package should be an automated part of creating new RaSCSI releases. If this requires additional manual work it might just be a matter of time until this is not done anymore. Then only outdated packages would be available, which would be bad.
• In the ideal case there would be automated nightly package builds of the develop branch.

[uweseimet]

Going to close this ticket as there does not appear to be sufficient interest in updating/improving the installation process. Also see #740. There are too many stale tickets already anyway.

[akuker]

Agreed. Thanks @uweseimet !