Use "/usr/local" as default prefix for "make install" #448
Conversation
Convential filesystem standards imply that "/usr" prefix should be used only by system package managers. Custom installations should go to /usr/local by default. However, we *should* keep "/usr" prefix for packaging, therefore override the default for "deb" and "rpm" targets.
|
How this will affect current users that have Themis installed in |
|
Good question... Assuming these are users that install from source code, I can see Similarly, if Themis 0.11 is installed to Overall, I feel that we will have to ask those users who install from source to cleanly uninstall previous version of Themis using previous source code, and then install an upgrade using the new source code. Alternatively, I think we could detect whether Themis is already installed to |
All previous installation of Themis from source on Linux used "/usr"
prefix. This means that installing a newer version into "/usr/local"
will result in two completely unmanaged side-by-side installations of
Themis. It is brittle and can cause all sorts of trouble, both when
building software and when loading shared libraries.
Add a shim for backwards compatibility for Linux. If we detect that
there is already a "make install" installation of Themis in /usr then
we keep using the old "/usr" prefix by default. Otherwise we use the new
"/usr/local" prefix. If the user has explicitly specified the prefix
then we go with that value regardless of the installation status.
It's kinda tricky to detect source-based installation. We do as follows:
1. Check for the main header file <themis/themis.h>
It is always installed by "make install", and it may be installed by
Themis package (DEB or RPM).
If there is no such file then Themis is not installed to "/usr",
we can simply use the new prefix.
2. Otherwise, check DEB and RPM packages
If there is "libthemis" package installed then Themis installation
is managed by the system's package manager. We should not use "/usr"
prefix to avoid overwriting system installation, use "/usr/local".
In this way we prefer "/usr/local" prefix if possible, avoid overwriting
installations by package managers, and keep using the old "/usr" prefix
if the user had Themis installed there before.
macOS has always used "/usr/local" prefix so we can just keep using the
default there.
|
@vixentael I've pushed a commit that implements the backwards compatibility behavior described in the previous commit. With that, on systems that do not have Themis installed (yet) we'll be using the new |
|
I'd avoid to set path automatically. How about next behaviour:
|
|
@shadinua, well, that's a reasonable approach as well. Though, I feel that installing a local version to Ideally, I'd avoid doing all this guesswork altogether (as it's bound to fail for someone, human perversion has no limits). If you install Themis from source then well, do manage your versions yourself if you insist on not using any sort of package manager. |
It's better for our users to know where do we install files to and where do we remove them from during uninstallation. Let's print the PREFIX value for "make install" and "make uninstall" targets.
|
I've added one more convenience for the users: now we print the installation prefix so the users know where Themis has been installed to or removed from. Now, what should we do about multiple installations and upgrades?
As for paths, I believe that we'd run into conflicts either way if we ever going to fix the mismatch on CentOS (libraries should go to |
By default
I completely agree. That is why I'd suggest to choose one of standard, predictable and simple variants to solve this issue. |
This is involves much more hassle than
Yeah, that's exactly the point. Imagine you're using PyThemis and there's some bug in the core library. Your core library is installed from package repositories. However, you are able to grab the latest source code, |
|
Another common approach is system-wide installation to I think that we can keep it simple by installing to specified prefix if it is explicitly requested by the user. If they request it, they have their reasons and did their homework. |
There are too many cases. For some of them, this is an advantage. For some — a disadvantage. These libraries can be installed not only on the developers' machines, where changing in the behaviour of the whole system is normal. In the proposed variant, parallel installation of the library using |
|
Well. I'll not insist on that behaviour. I'd prefer to have Makefile without any extended logic inside. Let's choose variant #4. But we have to implement CentOS detection to set correct paths. |
With this option I would feel better if we notify user that installation path was changed. For example, if we detect that Themis is already installed in |
This reverts commit 71edd43.
Changing default installation path from /usr to /usr/local is more or less safe on Linux as the compilers and linker-loaders *usually* check /usr/local before /usr. Therefore after "sudo make install" the software will (probably) be using the new version of Themis. However, the old installation may still remain there in "/usr" and this may cause issues with non-standard configurations. Check if there are multiple installations of Themis and print a warning for the users, suggesting to keep only one installation in their system.
|
@shadinua @vixentael I have reverted the 'AI-commit' and added a simple check with a warning if we detect Themis in both |
Conventional filesystem standards imply that
/usrprefix should be used only by system package managers. Custom installations should go to/usr/localby default. However, on Linux machinesmake installinstalls to/usr, messing with package manager installations. Let's install to/usr/local/everywhere.However, we should keep
/usrprefix for packaging, therefore override the default fordebandrpmtargets.