On Thu, Dec 15, 2016 at 11:03 AM, Jan Engelhardt wrote:

On Thursday 2016-12-15 17:01, Roger Oberholtzer wrote:

...

My problem is when I want to install the -devel package as well. In this case, I need to install libsndfile-devel. Note the missing '1' in the name.

My question is, given that I know the name of the library RPM, how can I derive the name of the -devel package? Sometimes it is just to add -devel to the name. Sometimes not.

1. rpm -qi libsndfile1 => gives you the SRPM name. 2. checkout openSUSE:Factory/$name/$name.spec and look for one or more devel subpackages.

Usually, you can install things using their pkgconfig() or cmake() Provides. for example, to install on openSUSE systems, you can use "zypper install -C 'pkgconfig(sndfile)'". On Red Hat/Fedora systems, "yum install 'pkgconfig(sndfile)'" works in the same manner. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Thu, Dec 15, 2016 at 5:26 PM, Malcolm wrote:

Zypper will also fine the file... zypper --no-refresh se -i -f libsndfile.so.1

OK. But that only works with the DSO lib files. Include files needed to compile for the package are not known in this context.

Maybe look at YaST add on creator to build a repo for all you files and deploy?

Which basically means I need to maintain a list. I was trying to avoid that. If I have a list, I can just as well have the names in a script somewhere. In either case, I would need to determine the names for the lib and -devel packages by hand... -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Dez 15 2016, Roger Oberholtzer wrote:

My question is, given that I know the name of the library RPM, how can I derive the name of the -devel package? Sometimes it is just to add -devel to the name. Sometimes not.

Most of the time it is the name of the source rpm + -devel.

Is there some brilliant way to do this reliably?

There is no reliable way, because people are creative. This has nothing to do with OBS really, as it depends on the policies of the distribution. For openSUSE, there is https://en.opensuse.org/openSUSE:Package_naming_guidelines. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On 15.12.2016 17:32, Roger Oberholtzer wrote:

On Thu, Dec 15, 2016 at 5:26 PM, Malcolm wrote:

...

Zypper will also fine the file... zypper --no-refresh se -i -f libsndfile.so.1

OK. But that only works with the DSO lib files. Include files needed to compile for the package are not known in this context.

Properly packaged libraries don't contain unversioned libraries. These are in the respective devel packages. in this case: zypper se -xf /usr/lib64/libsndfile.so will return libsndfile-devel Take the full path of the library, strip the versions after ".so", search with "-x" (exact match, otherwise you get libsndfile.so.1 as well). This should work in most cases; if it doesn't, please take the opportunity to file a bug. The exception to this would be plugins which are usually unversioned .so libraries in a special directory. But IIUC you are not concerned with these. hope this helps m. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

AFAIK there is no way to search for filenames in packages if they are not explicitly listed as Provides: or currently installed. But tools like this are available on other distros (apt-file), see also this discussion: https://features.opensuse.org/308437 On 12/15/2016 05:01 PM, Roger Oberholtzer wrote:

I have a script that makes a list of all the RPMs that must be installed to satisfy a directory full of binary programs. The RPMs are already installed. The purpose of the script is to get the list of RPMs so they can easily be installed on a different system.

I have no trouble finding the name of the RPM with the needed libraries.

For example,

rpm -q --queryformat "%{NAME}\n" --whatprovides /usr/lib/libsndfile.so.1

reports:

libsndfile1

So, "zypper in libsndfile1" does the deed.

My problem is when I want to install the -devel package as well. In this case, I need to install libsndfile-devel. Note the missing '1' in the name.

My question is, given that I know the name of the library RPM, how can I derive the name of the -devel package? Sometimes it is just to add -devel to the name. Sometimes not.

Is there some brilliant way to do this reliably?

-- python programming - mail server - photo - video - https://sebix.at cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers

On Thu, Dec 15, 2016 at 5:50 PM, Malcolm wrote:

Run ldd over the binary?

That's how I get the libs in the first place. I also found that running ldd on the libs I get this way catches a few more dependencies. I just can't get the ones an app loads with dlopen. You can't get everything. One reason we do this exercise is so we can be sure we are not violating any licenses. Instead of trusting some docs, we check the binaries and libraries direct. For this we don't need the -devel names. We set up various virtual machines (and the odd Raspberry PI) as development/test systems. It's nice to get the needed RPMs installed with minimum hassle. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Thursday 2016-12-15 17:38, Roger Oberholtzer wrote:

...

...

1. rpm -qi libsndfile1 => gives you the SRPM name. 2. checkout openSUSE:Factory/$name/$name.spec and look for one or more devel subpackages.

Obtain and parse the .spec file to get the -devel name?

Whatever it is you are looking for.

...

Usually, you can install things using their pkgconfig() or cmake() Provides.

for example, to install on openSUSE systems, you can use "zypper install -C 'pkgconfig(sndfile)'".

On Red Hat/Fedora systems, "yum install 'pkgconfig(sndfile)'" works in the same manner.

But I cannot deduce the name 'sndfile' from a compiled program.

Why would a compiled program care? (Also, you do not have to deduce "pkgconfig(sndfile)", because it is a known fixed string.)

my current method also reports the names of RPMs needed as a dependency of some library.

It is just the -devel RPM naming part that is, to me, inconsistent.

It is a compromise. RPM supports installing packages sharing the same name concurrently as long as they do not conflict. But doing that is brittle to the point that you cannot rpm -U your system without collapsing same-name packages to one. So in openSUSE, unique identifiers are used for shlib packages like libncurses5 and libncurses6. ncurses actually also highlights a case: there is just one devel and one srpm, not two. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Fri, Dec 16, 2016 at 1:47 AM, Jan Engelhardt wrote:

...

But I cannot deduce the name 'sndfile' from a compiled program.

Why would a compiled program care?

That's the whole point of the exercise: the information comes from compiled things. One reason for this is that we use proprietary libraries (e.g., Kakadu JPEG2000, or Intel Performance Primitives, or various Gig-E-Vision cameras) for which we only have a binary. And these have dependencies that we would like to include in our analysis. We do not have access to the source. (On Linux, be happy you even get a library for the transducer!)

(Also, you do not have to deduce "pkgconfig(sndfile)", because it is a known fixed string.)

In the build process, perhaps. Which is fine if you actually build the thing. But even that may not pick up all dependencies. For example, when a library is built, the link command to build the library can reference dependent libraries (of the .so type). Later, when a program links with this library, it need not specify these other dependent libraries. No reference is needed in the build process. So, relying on the build definition to tell all is no guarantee. But, looking at the resulting binary picks up everything.

It is a compromise. RPM supports installing packages sharing the same name concurrently as long as they do not conflict. But doing that is brittle to the point that you cannot rpm -U your system without collapsing same-name packages to one. So in openSUSE, unique identifiers are used for shlib packages like libncurses5 and libncurses6. ncurses actually also highlights a case: there is just one devel and one srpm, not two.

They would not have the same name. They should share the %{NAME} part, and add -devel or -src or whatever to that. The problem is that they may not share the %{NAME} part. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Fri, Dec 16, 2016 at 2:05 AM, Adrian Schröter wrote:

On Donnerstag, 15. Dezember 2016, 14:56:44 CET wrote Neal Gompa:

...

On Thu, Dec 15, 2016 at 1:32 PM, Sebastian wrote:

...

AFAIK there is no way to search for filenames in packages if they are not explicitly listed as Provides: or currently installed. But tools like this are available on other distros (apt-file), see also this discussion: https://features.opensuse.org/308437

That's not true for DNF, Yum, or Zypper. All of them have a way to search for files through the repodata, and match it to packages.

the repodata usually contains only files from selected directories though.

No, the rpm-md repodata has the full file list. The primary.xml.gz includes a selected subset, yes, but filelists.xml.gz contains the full file list. OBS unfortunately ignores both file lists, but they are there. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Fri, Dec 16, 2016 at 12:18 PM, Neal Gompa wrote:

I'm not sure what you're talking about. The "pkgconfig(sndfile)" string is generated by reading the pkg-config file during the packing process and reading the names. The dependencies described in the RPM are from the pkgconfig file and from the built resultant binaries. This is why even nosrc RPMs are able to be built with full dependencies described.

And usually, you know the pkgconfig() name because it's the same name you use for pkg_check_modules() in autotools and CMake. If you don't even know that, then you might be doing this wrong...

The binaries that are being checked are not on OBS and may not be in an RPM at all. The checking is not part of any packaging of the binaries. It is a check of what a group of binaries need (1) in order to run and (2) in order to be compiled. #1 is easy. #2 is less easy. The binaries do, however, use things from OBS. Which is why I am asking on this list. I am just trying to figure out what the OBS dependencies are. It is the -devel part that is the issue because of inconsistent RPM naming. The reason for this naming is, I guess: 1. There can be two versions of a package, each with, say, libraries with different versions. Like libabc.so.5 and libabc.so.6. Each is in an RPM with a different name, and so they can easily be installed together - the RPM has the version as part of the name, and the contents have different names. Programs that were linked against either will run as both can be present at the same time. The RPMs would be something like: libabc5-1.rpm libabc6-1.rpm 2. The -devel package will contain libabc.so (not the libs listed above), which is a sym link to either libabc.so.5 or libabc.so.6. Newly compiled things will link with -labc, But it is what the symlink points to that is put in the binary. libabc.so is only used/needed when linking something new. Note that one cannot have the development package for both version installed at the same time. By not including the version in the -devel name, this will be enforced by the package installer. The problem with this is (1) you cannot develop against both versions (include file differences add to the dilemma), and (2) there is no way by looking at the name of the -devel RPM that you can tell which version it is for. The RPM name would be (for either lib version 5 or 6): libabc-1.rpm I am saying all this so it is understood that I get why things are named as they are, and what it solves. I just want to add that it does present other issues. How about a tag in the RPM that tells the name of the development RPM? RPM could provide is as %DEVEL% -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On 29/12/2016 15:49, Dave Plater wrote:

Sorry I'm late, try zypper in `rpm -q --whatrequires libsndfile1|grep devel |cut -d - -f 1,2` Regards Dave P

-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org