Is the submission of libopenmpt still pending?

Ook, sorry, no. That was https://build.opensuse.org/request/show/808568, which @mia accepted a few days ago :)

@dimstar, @elvigia, @jjolly, @mseben, @plater, @seife, @sreeves1, @tiwai

Is there anything else holding up accepting this new package? Without it, a large number of packages in the repo fail to build....

As mentioned in the note when I originally submitted this package, the compile code inside the tarball SETS THE SONAME in the built library to libopenmpt_modplug.so.1 -- if I try to BUILD a package with a single library inside it in OBS, the rpmlint that is run automatically FORCES the package name to be EXACTLY libopenmpt_modplug1. OBS will not allow any other package name in these circumstances - I've tried several, and this is the only one it will accept. I was strongly averse to changing the soname as it was defined by the library developers, so instead I bowed to OBS's mandate and named the package as it demanded.

If you find this "Not acceptable" then take it up with OBS, not ME. If you end up building your own (which you will if you ever want to have all the dependent packages build again) you'll very likely end up making the same choices I was forced into in the process.

Apologies Thomas - certainly I appreciate that you are trying to fix the gap; by declining your request I did not mean to be disrespectful to you in any way.

The problem with his request as-is are:

• The Name: tag must match the package name in OBS (this is mostly a requirement for the distributions, OBS is perfectly happy the way it it). This requirement comes from attempts to eliminate the confusion when looking for packages. the src.rpm tag in packages matches the package name in obs if this is upheld; in you case, you get a different src.rpm tag as compared to the package name (not far off, yet, far enough to not be equal)
• The source package name should never follow the shared library versioning (i.e …1 in this case). The library can potentially change the version in the future (however unlikely, it can and most likely will happen if the library keeps on being developed). As we do not want to rename the package with future versions, the rule is to not have the version in the package name (so Source: libopenmpt-modplug - same as upstream clals it)

This in turn will mean you get in the spec file things like:

Name: libopenmpt-modplug
Version: 0.8.9.0

%package -n libopenmpt_modplug1
…
%description -n libopenmpt_modplug1
…
%package devel
…
Requires: libopenmpt_modplug1 = %{version}

%description devel
…


%files -n libopenmpt_modplug1
%{_libdir}/libopenmpt_modplug.so.1*

%files devel
…

This will allow the package container name to remain the same, even when the version will potentially change in the future.

A special note to the devel package: this one also does not contain the library version - just like the main package. Again, consumers of the devel package should not have to worry about the version and be able to always BuildRequire libopenmpt-modplug-devel. Additionally, it's important to note that the devel package in the current form is lacking header information (*.h files); it's close to impossible for a consumer to build against this library without this information (likely a bug upstream, that make install is not putting those headers in place)

I sure hope you do understand that the comments are not meant o patronize you, but to help you see the picture also for the future. Trying to do the right things now and taking the (most probable) future into account helps to save time down the road.

@dimstar, @elvigia, @jjolly, @mseben, @plater, @seife, @sreeves1, @tiwai: review reminder