Indeed, thanks for fixing this! We have a workaround in our downstream packaging which I've long forgotten about:

# fix location of NSS modules
cd debian/install/deb/; for f in usr/lib/*/libnss_*; do mv $$f $${f#usr/}; done

There was no such workaround in OE and I ended up tracking why resolved was not used at all.

BTW. ubuntu jobs seem to be failing due to this:

# fix location of NSS modules
cd debian/install/deb/; for f in usr/lib/*/libnss_*; do mv $f ${f#usr/}; done
mv: target 'lib/s390x-linux-gnu/libnss_systemd.so.2' is not a directory

Is there something I can do about that?

I made the downstream packaging workaround more cautious so that it should now get along with upstream make install already doing the right thing: https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=8b58cd858

Restarted the failed tests to run against the above fix.

Thanks!

The current Makefile uses the move-to-rootlibdir() function for the existing cases (libudev and libsystemd) and does it this way:

libsystemd-install-hook:
        libname=libsystemd.so && $(move-to-rootlibdir)

I think explicitly installing into rootlib_* is simpler and would avoid the move-to-rootlibdir funtion altogether. IMHO we should either use that function for the NSS modules as well or move lib{udev,systemd} to use rootlibdir as well (which appears simpler and thus preferrable).

@keszybz , you touched it in commit 24fdc23, do you have an opinion about this?

I think I just refactored the existing code, without thinking about a simpler replacement :(
So yeah, also replacing the move-to-rootlibdir hook with the use of rootlib_* sounds good.

Sounds good to me. I'll push another patch.

In my testing this patch (both the --split-usr and non-split versions) makes no changes to the installation tree. Merging. Ubuntu tests probably need some more adjusting @martinpitt.

24 wrz 2016 18:08 "Zbigniew Jędrzejewski-Szmek" [email protected]
napisał(a):

In my testing this patch (both the --split-usr and non-split versions)
makes no changes to the installation tree.

Yeah, split-usr only affects bin/sbin dirs.
You'd need to pass --with-rootlibdir to see any changes. We do that in OE
recipe, perhaps Ubuntu does the same in their debian/rules.

"makes no changes" is a good thing — I was just confirming that the installation is same as before with the second patch. Everything is OK afaict.

Ubuntu tests probably need some more adjusting @martinpitt.

The package build scripts do, but I already adjusted them. Thanks!