Comment # 1 on bug 966956 from Jan Engelhardt

Some thoughts on that..


I have a system where at least five libraries of the pack are definitely not
installed while mc (uses libsmbclient) is.

package libdcerpc-atsvc0 is not installed
package libdcerpc-samr0 is not installed
package libregistry0 is not installed
package libsamba-policy0 is not installed
package libwbclient0 is not installed
(libsmbclient0-4.3.4-1.1.x86_64)

Combining them again may cause a loss in that regard.

A combination also means all those files start requiring to be updated in
lockstep, which is an arbitrary limitation. If libsmbclient.so.0 were bundled
in samba-libs (or samba-client-libs, whatever), then if libsmbclient.so.1 comes
along, you would leave no way to have a libsmbclient0 in the system whilst
having a new samba-client-libs.

The lockstep clause of the Shared Library Packaging Policy which e.g. libqt4
made use of, only works if it can be ensured that future SO versions of the
files shipped in one RPM subpackage are equal in value, and changing at the
same time when they change. I am not convinced that samba is making this
guarantee as hard as qt4 did.

I do see the possibility though; libdcerpc and libdcerpc-binding almost sound
alike and could be potential candidates for combination -- also because
libdcerpc-binding appears not to have a separate devel package of its own.

>Instead this package design causes version update by version update
>additional maintenance works as the baselibs.conf has to be redefined.

It is an atrocity that we even have to declare baselibs.conf for trivial SLPP
packages. That is a shortcoming in {/usr/bin/build,/usr/bin/mkbaselibs}'s
defaults which I already bemoaned years ago, but since apparently only code
talks, that is now my cue to implementing it.

:

With all these points, the split libs should generally be kept and at most
minimally be adjusted.