On Mon, Jun 06, 2022 at 08:55:20AM -0700, Davide Erba wrote: > I am trying to install a git repository, complexespp > <https://github.com/bio-phys/complexespp/tree/main/complexes%2B%2B>, which > requires the external repository yaml_cpp > <https://github.com/jbeder/yaml-cpp>. While running the last step of > installation of complexespp > sudo make install > I face the following problem: [...]
I'm inclined to state you're trying to solve a problem you should have not been trying to solve in the first place. Let me explain by providing some insight on how a software package should be installed on a typical contemporary GNU/Linux system. In the Unix ecosystem - and especially in its "inner" ecosystem of GNU/Linux - parts of software packages which take care of installing the results of "building" (compiling etc) of those packages traditionally default to installing their stuff into the "system-owned" locations of the filesystem - into the directories such as /usr/lib, /usr/share/..., /usr/bin, /usr/sbin and so on. Normal users do not have write access to these directories, and from that comes a glib advice of running commands such as `make install` with elevated privileges: you know, unless specially reconfigured, in a stock Ubuntu, running `sudo any_command` will run `any_command` as the system's superuser, root, for which almost no permission checks are performed when accessing filesystems and other resources. While this sounds as a sensible approach to solve the problem of installing software packages from their source code, it is not - for a number of reasons: - The way most (I think it's reasonable to say "all") software packages implement installation of their generated executable and auxilliary files is via plain scripting. I mean, no matter whether you run `make install` or something else, in the end a bunch of programs like `mkdir`, `cp`, `install`, `chown`, `chmod`, `ln` and so on are run to copy the generated files into the various locations on the tagret filesystem and tweak the permissions on them. As a result, such installation process is completely oblivious to whether such copying of files would overwrite any files already existing on the file system and belonding to different packages. (Note that the term "package" is unfortunately overloaded: here I'm talking of the software packages provided by the system which you manage using system-provided tools such as the Software Center, `apt` and so on.) - Many software packages do only provide for installing their stuff, but not for uninstalling. Hence you can run `sudo make install` to install stuff, but you'll unlikely be able to run `sudo make uninstall` to undo that. What's more, if the software package provides a way to uninstall its stuff, that process necessarily depends on that the configuration of the source package had not changed since the installation, and that this package is itself present - so you can have the source tree to run `make uninstall` in. Add to that that uninstallation is rarely tested by the devs, even if provided. - Once `sudo make install` or something like this had finished running, you have no visible record of which files have been installed by that process, and where. So, what could you do about this? I'd recommend either of the following two ways, or a combination of them. The first is to use the venerable package checkinstall [1] which is available in the stock Ubuntu, so you can just `apt install` it. Checkinstall uses a set of clever tricks to "virtualize" filesystem access for the command it controls, records what it does, and creates a proper software package as a result. For instance, running $ sudo checkinstall make install would create a DEB package containing the stuff `make install` would install if run as `sudo make install`. You can then install the generated package by running # dpkg -i that_package.deb and then later uninstall it using `apt remove that_package`. Since the package would be installed by dpkg, it will check for any conflicts with the files installed by other packages so it's impossible to silently overwrite files owned by other packages. The second is to exploit the possibility that most software packages (at least sensible ones) allow overriding of the installation locations for their files. At the bare minimum, most packages support the PREFIX environment variable to set the root path of the hierarchy to install the files. You can use this to install the package's files somewhere under your home directory - which does not require superuser permissions and installs all the files in the single place. How do to that for your package of interest is detailed in [2] - you could run $ cmake -DCMAKE_INSTALL_PREFIX:PATH=/home/davide/complexespp .. and then $ make install (without the `sudo`!) would install everything under ~/complexespp, with the executable files available under ~/complexespp/bin, as documented. The combination of these approaches could employ the fact any typical GNU/Linux system provides a special place on its filesystem for "locally installed" packages - /usr/local. So you could run $ cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr/local .. and then $ sudo checkinstall make install to generate an installable package. Having said that, I'd note that running `checkinstall` requires root permissions so it's most likely to trigger the same problem you have with running `sudo make install`, so I'd either try to install under your home directory as explained above or would first convince Git to not issue that warning - providing the pointers offerred by Philipp, - and then would use `checkinstall` to create a proper installable system package. 1. https://packages.ubuntu.com/checkinstall 2. https://github.com/bio-phys/complexespp/tree/main/complexes%2B%2B#installation -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/20220607103353.neh76oytiwcy7ey2%40carbon.
