'revdep-rebuild -p' throws >broken /usr/bin/links (requires libssl.so.0.9.6 libcrypto.so.0.9.6) even though i remerged it after upgrading to openssl 0.9.7 pre14 supports smb:// urls via smbclient -> samba ? dependency
Created attachment 25667 [details] Try this one for links-2.1_pre11
Created attachment 25668 [details] And this one is the new one for links-2.1_pre14
Carlo, Thanks for the bug report, I hope this to new ebuilds solve the problem. Regards, Ingo -LaSombra- Hoffmann
Thx, Ingo. Unfortunately the pre14 version is limited to =openssl-0.9.6*, too.
Hmmmm, strange. My OpenSSL is 0.9.7 something and links is working fine. And the OpenSSL is not restricted to version 0.9.6 in pre14, "ssl? ( >=dev-libs/openssl-0.9.6c )" see? Why don't you output your emerge -vp? That should do the trick in helping us. Sorry for not beign precise, but I'm using Windows on work now :(
Are you sure Ingo? The 0.9.7 ebuild preserves the older libs, so if you don't remove them by hand, you won't notice. Just remerged openssl, deleted the 0.9.6 libs and remerged links afterwards. Same problem. On the other hand, I'm wrong. The older libs are preserved by the 0.9.7 ebuild and it's more or less my problem, that I want to get rid of them. At least I could point you to the optional samba dependency. :)
Well, have to go home to check the openssl stuff, but I'm pretty sure 0.9.7 removes the 0.9.6 files, but well, we can always be wrong ;) About the samba option, that's why we are here, listening to issues and resolving them :D
>Well, have to go home to check the openssl stuff, but I'm pretty sure 0.9.7 removes the 0.9.6 files from pkg_postinst(): test -f ${ROOT}/usr/lib/libssl.so.0.9.6 && { einfo "You can now re-compile all packages that are linked against" einfo "OpenSSL 0.9.6 by using revdep-rebuild from gentoolkit:" einfo "# revdep-rebuild --soname libssl.so.0.9.6" einfo "# revdep-rebuild --soname libcrypto.so.0.9.6" einfo "After this, you can delete /usr/lib/libssl.so.0.9.6 and /usr/lib/libcrypto.so.0.9.6" This means the user is expected to delete the libs, but links doesn't work witout them, so I think my report is still valid.
Well Carlo, I just installed a new system and it didn't installed 0.9.6 at all hoffingw@bss40h3f21 hoffingw $ ldd /usr/bin/links2 linux-gate.so.1 => (0xffffe000) libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x40019000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x4004a000) libdl.so.2 => /lib/libdl.so.2 (0x40149000) libm.so.6 => /lib/libm.so.6 (0x4014c000) libc.so.6 => /lib/libc.so.6 (0x4016e000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) hoffingw@bss40h3f21 hoffingw $ But, if openssl ebuild says you have to delete it by hand, it's nothing links ebuild can do for it... Don't you agree? ;)
Sure, the old libs are only preserved, if they existed before. The question is: Does links work on your fresh installed system? And if it does, why does it not work here? And yes - I merged links again, after deleting the old libs.
O.k., I did: #> ccache -C #> rm -rf /var/tmp/portage #> ACCEPT_KEYWORDS="~x86" emerge links #> ldd /usr/bin/links libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40035000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4005a000) libz.so.1 => /usr/lib/libz.so.1 (0x40086000) libssl.so.0.9.6 => not found libcrypto.so.0.9.6 => not found libdl.so.2 => /lib/libdl.so.2 (0x40094000) libgpm.so.1 => /usr/lib/libgpm.so.1 (0x40098000) libm.so.6 => /lib/libm.so.6 (0x4009e000) libvga.so.1 => /usr/lib/libvga.so.1 (0x400c0000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4012a000) libc.so.6 => /lib/libc.so.6 (0x40207000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) libncurses.so.5 => /lib/libncurses.so.5 (0x40334000) But I have only libssl.so.0.9.7 and libcrypto.so.0.9.7 on my system. I have absolutely no idea why this f*cking ebuild treats me like this. :|
Hmmmmmm, very very strange... I'll deep double check it, but yes, it works on new systems :)
Just a very stupid question, but habe to ask. Your ssl, crypto symlinks are ok, right?
Oh forget it. If the problem is really tricky, it sits _always_ in front of the screen. -rwxr-xr-x 1 root root 2904148 20. Aug 2002 links -rwxr-xr-x 1 root root 2971464 21. Feb 01:41 links2 The links executable must be from my early Gentoo days...
To clearify this: I remerged pre11 - it works with openssl 0.9.7, too.
Ok, I've found what's happening and I'll be working on a solution soon. For some reason you have the file /usr/bin/links instead of the symlink links -> links2. One thing you can do to solve this is to remove the /usr/bin/links file and create the apropriate symlink or re-emerge links. I didn't find a reason why you have the links file, but it exists :-/
> Ok, I've found what's happening and I'll be working on a solution soon Fixed it for me already. I think previous ebuilds did something like cp instead cp -d when merging from sandbox to system, but the later ebuilds which don't dereference the symlink can't overwrite the existing file. Instead if [ ! -f /usr/bin/links ] then dosym links2 /usr/bin/links fi in the links ebuild (or a fixed version, which deletes existing files, before adding the symlink) this code should be part of the dosym script itself.
a requirement is to disable the sandbox for deletion of the existing file, of course
Yepz, I agree with your comments, but I guess you was the only one with that problem so far and the solution is well documented in this bug report so we can update the ebuilds attached and close this bug, what do you think seemant?
Maybe I'm the only one who detects this small problem _and_ writes a bug report. I know for sure that there were other ebuilds just copying symlinks without the -d option. Can't remember which, though.
Yeah, but what you did is the best way to solve such small things that are a pain in the ass after 3, 4 hours emerging a new system. Thanks again for the report and I hope everything should be working normally from now on. Best regards Carlo, Ingo -LaSombra- Hoffmann
Imho 'the best way' is avoiding such problems (in future), instead fixing them manually every now and then again. But it's more a portage than ebuild problem, of course.
Hmmmmm, I agree, but I think this kind of problems are becoming very small now and it strikes more on portage updates than on ebuilds updates ;)
what's the status of this?
Don't know what you devs want to do. I still think the dosym script should be fixed (and if it is only to prevent bug reports like this one in future).
For the links part, the ebuilds are ready for deployment, but I dunno where the symlink problem is. I believe it's not on the ebuild, but...
I'll be closing this bug report that I guess is fixed for the most of us. Any future problems please, contact me or open a bug report, as you wish :) But I need to remember that these ebuilds should be commited as soon as possible. Best regards, Ingo -LaSombra- Hoffmann
