On Thu 15 Dec 2016 11:10:44 AM CST, Neal Gompa wrote:

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.

Hi Zypper will also fine the file... zypper --no-refresh se -i -f libsndfile.so.1 Maybe look at YaST add on creator to build a repo for all you files and deploy? -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.1|GNOME 3.16.2|4.1.36-41-default up 2:03, 3 users, load average: 0.35, 0.35, 0.25 CPU AMD Athlon(tm) II X4 635 @ 2.90GHz | GPU Nvidia GeForce 8800 GT -- 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

On Thu, Dec 15, 2016 at 5:10 PM, Neal Gompa wrote:

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.

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

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. And, 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.

-- 真実はいつも一つ！/ Always, there's only one truth!

-- Roger Oberholtzer -- 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: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 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 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 Thu, Dec 15, 2016 at 5:44 PM, Andreas Schwab wrote:

There is no reliable way, because people are creative.

Hmmm. This difference in naming is so pervasive that I thought there was some rule.

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.

I see references to the fact that the -devel packages may exist. But I did not see where the naming policy is. So I guess there isn't one. OOC, in yast, when enabling showing -devel packages, I guess if just looks for '-devel' in the name. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

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.

Zypper can do it with "zypper search --file-list <file-path>"

-- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org