On Thu, Mar 17, 2016 at 10:12:19PM +0100, Bjoern Voigt wrote: [ 8< ]
One concrete example. Pulseaudio uses the directory /usr/lib64/pulse-8.0 for it's modules:
# ls /usr/lib64/pulse-8.0/modules libalsa-util.so module-device-restore.so module-remap-sink.so libavahi-wrap.so module-echo-cancel.so module-remap-source.so [...]
You can inspect /var/log/zypp/history and there you'll see that the pulseaudio-%{pa_version} package got upgraded while some of the subpackages are still at the former version. pulseaudio-module-lirc for example with 7.1-1.2 version-wise. One fix would be to add %dir %{_libdir64}/pulse-%{pa_version} %dir %{_libdir64}/pulse-%{pa_version}/modules to every pulseaudio-SUBPACKAGE_NAME-%{pa_version} package. The other is to get the grouped RPM resolution/ installation implemented at the libzypp level. In this case all the pulseaudio packages would be handled with one RPM transaction. I consider this a non low hanging fruit. Else the zypp developers would have implemented it already. Even the announced commit.downloadMode = DownloadInHeaps wasn't implemented when I last gave it a try. I expect there are more pressing issues. [ 8< ]
But what is a good strategy here? I can manually check and delete the empty directories. And I can write a bug report for every single RPM package with missing "%dir" options. But this would be time-consuming.
I would prefer an automatic RPM check in build service for this. Is there something or something planned?
This isn't easy to catch I fear. Cause RPM-wise the PA packages - to stay with this example - are correct. Check the OBS build log and you'll see how the packages get installed and removed at the end in the intended order. But libzypp of the later used actual system doesn't care. To get this solved I would add the two directories to every PA package and also handle any other problematic cases the sane way. But only if the zypp developers have a better idea. Or if the RPM folks complain to blow up the RPM db by following the suggestion. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany