#1556 PR `closed`: choose relative link-target for lib-dirs - fixes #1555¶

Labels: bug, won't fix / can't fix / obsolete

efwe opened issue at 2017-10-29 08:50:¶

Hello @gozora,

as today is really awful weather I looked around the rear-source.
There I found this script which creates the lib-environment.
I'm not sure what else breaks with this - so this PR is more meant like
a question/pointer start of discussion than a real merge-request.

But with this fix my chrooted rootfs looks better (for /usr/lib64 at least)

RESCUE osa:/usr # ls -l /usr
total 0
lrwxrwxrwx 1 root root    6 Oct 29 08:36 bin -> ../bin
drwxr-xr-x 2 root root   60 Oct 27 18:13 include
drwxr-xr-x 8 root root 4340 Oct 29 08:36 lib
lrwxrwxrwx 1 root root    3 Oct 29 08:36 lib64 -> lib
lrwxrwxrwx 1 root root    6 Oct 29 08:36 sbin -> ../bin
drwxr-xr-x 8 root root  180 Oct 29 08:36 share

and the ldd of course also works now.
Maybe this helps, greetings
Frank

gozora commented at 2017-10-29 09:08:¶

Yep, hell of a weather here as well.
I'm installing Arch right now :-).
I know about that script, problem is that such approach would most probably introduce some regression, so we must be 100% sure that other distros will not suffer with such change.

gozora commented at 2017-10-29 09:13:¶

ReaR can distinguish between distros and can run some scripts if it matches. (see e.g. /rear/usr/share/rear/build/Debian).So I think this might be a way to go ...

V.

gozora commented at 2017-10-29 12:00:¶

Hello @efwe,

I've created PR https://github.com/efwe/rear/pull/1, can you check if it works better ?

V.

gozora commented at 2017-10-29 12:07:¶

@efwe
Your patch have some side effects:

++ target=usr/lib
++ [[ ! -e /tmp/rear.ninx3H9jappyoDX/rootfsusr/lib ]]
++ mkdir -v -p /tmp/rear.ninx3H9jappyoDX/rootfsusr/lib
mkdir: created directory '/tmp/rear.ninx3H9jappyoDX/rootfsusr'
mkdir: created directory '/tmp/rear.ninx3H9jappyoDX/rootfsusr/lib'

Which creates some directories rootfsusr and rootfsusr/lib which are not desired.
I did not study it further but this might be the recursion I was talking about earlier.

Btw. forget about my https://github.com/rear/rear/pull/1556#issuecomment-340247597, this is certainly a bug which can affect any distro, so we should not cover but fix it instead ...

V.

efwe commented at 2017-10-29 12:38:¶

Hello @gozora,

I tested with your patch and no errors during copy. The lib64 links looks great and no errors for ldd later of course. But I haven't booted or restored from it yet.
Especially because I now have other warnings

2017-10-29 13:27:52.630054166 There are binaries or libraries in the ReaR recovery system that need additional libraries
2017-10-29 13:27:52.635411950 /usr/lib/systemd/systemd-journal-remote requires additional libraries
2017-10-29 13:27:52.650156793   linux-vdso.so.1 (0x00007ffd78fee000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fb680f9a000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fb680be3000)
        libsystemd-shared-235.so => /usr/lib/systemd/libsystemd-shared-235.so (0x00007fb6807b1000)
        libmicrohttpd.so.12 => not found

but I will investigate first and open another ticket if needed.

So should I close this PR here and you can double check with someone else and use your patch? Thanks for the prompt effort. Very tough response time :)

Have a nice weekend,
~fw

gozora commented at 2017-10-29 12:50:¶

Hello @efwe

Especially because I now have other warnings

AFAIK we don't have many Arch users, so ReaR is not heavily tested here, hence you might run into some difficulties for sure ;-).

but I will investigate first and open another ticket if needed.

Sure, do so, If we know we help ;-)

So should I close this PR

Yes, please close it, I'm very far from being GIT guru and I really don't how to handle such situation correctly. So best would be to close this PR and I'll create new one with my changes and ask for review of other members.