How to determine Zypper install paths?

English Applications
1

I’ve recently bought a server from a colleague for large computations with openSuSE. I’m new at being my own sysadmin. This guy occasionally had to install different versions of things like HDF5, NetCDF, and MPI. He has been a huge help, but doesn’t always remember what he installed, and where.

I’m trying to port a climate model onto this new system, but I’m having all sorts of issues with my PATH, linking library versions, etc. I’d like to keep the zypper version of various libraries and compilers as much as possible. I’m slowly working through the issues, but it would be a HUGE help to know where zypper installs things. Is there a set of default paths? For example, are shared libraries always put in /usr/lib64/ instead of /usr/local/lib64/?

Another example, I have 2 “mpi.mod” files/usr/lib64/mpi/gcc/openmpi/lib64/mpi.mod
/usr/local/include/mpi.mod
and GCC is complaining about not finding mpi.mod, but how do I figure out which one to use? Which one is associated with the zypper version that I installed?

I’ve been googling this for days, but I can’t find any info, so any advice or resources would be appreciated.

2

Zypper installs PRMs. And inside a PRM is defined where all the bits and pieces go. Not in zypper.

BTW this has nothing to do with the contents of the PATH environment variable that normaly is available to user processes. That PATH variable is a list of directories to search for a command when given in a shell without further directory specification. Thus when in

program x y z

program is not an alias or shell a build in command, the PATH directories will be searched (from left to right) if the file program can be found.
This has nothing to do with where to install files from a PRM.

3

On 2015-05-12 15:56, whannah wrote:

> I’m slowly working through the issues, but it would be
> a HUGE help to know where zypper installs things. Is there a set of
> default paths? For example, are shared libraries always put in
> /usr/lib64/ instead of /usr/local/lib64/?

Well, you see, the decision is not up to zypper, but to whoever created
each individual rpm package that zypper (or anything else) installs.

There is a standard, the FHS, and there are openSUSE package guidelines.

For instance, a package created for distribution should not use
/usr/local/ at all. That path is reserved for things you build and
install yourself.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

4

Ok, thanks, this helps a lot. I’m much more familiar with stuff in the Mac world like macports, which always installs stuff into the /opt directory.

So is there a way, for multiple copies of a given library (ex. libxyz.a), that I could figure out which one was put there by zypper?

Maybe a better question is, how do I look at the rpm and ask where it “wants” to be installed?

5

If you have an rpm called example.rpm as a file (not installed) on your PC try:


rpm -qlp example.rpm

Lets say instead, the rpm “example.rpm” is already installed on your PC. In that case you do not need the ‘p’ and what should work is:


rpm -ql example

ie note I dropped both the “p” and the “.rpm” extension.

In some cases the app version # is built into the rpm file name, together with an additional version # that is not part of the rpm file name, so one needs to be a bit astute here.

6

On 2015-05-12 17:46, whannah wrote:

> Ok, thanks, this helps a lot. I’m much more familiar with stuff in the
> Mac world like macports, which always installs stuff into the /opt
> directory.

Have a look here:

Or “man hier”.

> So is there a way, for multiple copies of a given library (ex.
> libxyz.a), that I could figure out which one was put there by zypper?

Yes.


rpm -qf /pathtowhatever/file

Will tell you the rpm that file came from.

Maybe a better question is, how do I look at the rpm and ask where it
“wants” to be installed?


rpm -ql path/rpmname

Will list the files an rpm contains - but wait, it has to be installed
already. If it is not installed… mmm… what I do is that I browse to
it with ‘mc’ (Midnight Commander), hit enter on it, and I get a virtual
filesystem of the inside of the rpm, so that I can see each file where
it would go.

I’m not familiar with Macs, but a bit with Windows. In Windows it is
typical to install each program in its own directory. In Linux, instead,
the normal thing is that the program goes to /usr/bin, the libraries to
/usr/lib/, global config files to /etc, user configs and data somewhere
in /home… etc. More complex than that, but it is the initial idea. And
there is a standard where each thing should go. It is quite organized.

/opt is typically used by “external” programs that don’t come from the
distribution.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

7

As others have described, when zypper installs a package (of files) it only follows the instructions of the packager and doesn’t modify those instructions.

The main tools I use to “discover” where an app is…
Where are files related to the main app?
I use locate, install mlocate and do an updatedb immediately and then only if any files you’re looking for might have changed within the last 24 hrs

zypper in mlocate
updatedb

Then, one of the basic searches might be to just search for anything with the app name in the path

locate *appname *

Contents of an installed package
As others have described, some version of “rpm -q” will display the contents of a package. I use

rpm -ql *packagename *

The above describes how to find and display the specific files of an application, but not necessarily libraries it’s using and whether your app can automatically find a custom library. Ordinarily libraries are installed in a default existing PATH or /usr/lib/ or /usr/lib64/, but sometimes apps (particularly older) don’t do what they should.

There are the usual way to display the existing PATHs

echo $PATH

You may also want to display the shared library path

echo $LD_LIBRARY_PATH

If your custom library isn’t in those or /usr/lib/ or /usr/lib64/ then you may need to either move your library to an existing default path location or modify one of the two PATHs to point to your installed location (again, the locate utility can be useful to find lost file locations).

HTH,
TSU

8

Thanks everyone. The “rpm -q” thing is just what I was looking for.

On a related note, I looked at the file system standards page that robin_listas posted (thanks!), but I have a “best practices” question that I can’t find the answer to.

There are certain things that I absolutely need to build from source for what I’m doing, like netcdf-c, netcdf-fortran, and openmp. In the past, I never had root privileges so I just built these in directories within my home directory. Now that I am my own sysadmin, I’ve been told that if I want these things to be available to other users (which I do), I should really be installing these into /usr/local/, but I’m not sure what the best practice for this is.

Like for netcdf libraries, should I use --prefix=/usr/local/ or add a sub-directory like --prefix=/usr/local/netcdf/?

I can’t determine if this is a matter of taste, or something more. In either case, it’s a trivial matter to point the PATH or LD_LIBRARY_PATH to those directories, but is there any reason to use one strategy over the other?

Thanks,
Walter

9

Hi,

Like what most folks already said here, if you are building/compiling locally then the local is for you and since the normal PATH in openSUSE has those directory included then yes most users has access to it. The output of

echo "$PATH"

That said, since you’re the admin of that system then you can put it any directory you want as long as that directory is included in output of

echo "$PATH"

:slight_smile:

10

On 2015-05-13 21:46, whannah wrote:

> There are certain things that I absolutely need to build from source for
> what I’m doing, like netcdf-c, netcdf-fortran, and openmp. In the past,
> I never had root privileges so I just built these in directories within
> my home directory. Now that I am my own sysadmin, I’ve been told that if
> I want these things to be available to other users (which I do), I
> should really be installing these into /usr/local/, but I’m not sure
> what the best practice for this is.

That’s correct.

> Like for netcdf libraries, should I use --prefix=/usr/local/ or add a
> sub-directory like --prefix=/usr/local/netcdf/?

Just “/usr/local/”. The creators of that package will surely have
defined the proper paths.

In other words: the creators will probably expect to use a tree that
contains …/bin, …/lib, …/share, …/man, etc., all of them under
“/usr/local/”. Some of those directories are on the default path. If you
use “/usr/local/something/”, that one will not be on the path, unless
you also set the path yourself…

Some packages, when you tell to install under “/usr/local/”, will on
their own use “/usr/local/something/”, but they will also create a
script in “/usr/local/bin/” that is in the path, and will set the
appropriate environment.

>
> I can’t determine if this is a matter of taste, or something more. In
> either case, it’s a trivial matter to point the PATH or LD_LIBRARY_PATH
> to those directories, but is there any reason to use one strategy over
> the other?

The strategy of less work :wink:

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

11

Great, Thanks!