With older EAPIs dobin copies symlinks as target files. Thus, if I have in bin/ several binaries and some symlinks to them, what happens is that "dobin bin/*" installs all as files, not transferring the symlinks. In http://devmanual.gentoo.org/ebuild-writing/eapi/index.html you say: <quote> doins symlink supports Within EAPI=4, doins supports installing symlinks as symlinks when installing recursively. For older EAPIs, the symlink behaviour is undefined. </quote> It is not clear what should I do in this case: insinto /usr/bin dosym bin/* ? No, I would hope that dobin is finally smart enough to realize some files and symlinks and transfer them. Either way, please explain whether dobin finally respects symlinks or not in EAPI=4.
Neither "dolib" nor "dosym -r lib/*" transfer symlinks correctly. Or, they get converted to copies of files later on? For example, this happens to me: # MAKEOPTS=-j1 emerge sra_sdk Calculating dependencies... done! >>> Verifying ebuild manifests >>> Emerging (1 of 1) sci-biology/sra_sdk-2.1.9 from science [cut] >>> Installing (1 of 1) sci-biology/sra_sdk-2.1.9 /sbin/ldconfig: /usr/lib64/libvdb.so.2 is not a symbolic link /sbin/ldconfig: /usr/lib64/libkfs.so.1 is not a symbolic link /sbin/ldconfig: /usr/lib64/libalign-access.so.1 is not a symbolic link /sbin/ldconfig: /usr/lib64/libsradb.so.3 is not a symbolic link /sbin/ldconfig: /usr/lib64/libalign-reader.so.1 is not a symbolic link /sbin/ldconfig: /usr/lib64/libwvdb.so.2 is not a symbolic link [cut] # ls -la /usr/bin/sff-dump* /usr/lib64/libwvdb.so* /usr/lib64/libwsradb.a* -rwxr-xr-x 1 root root 73117 Mar 15 22:16 /usr/bin/sff-dump -rwxr-xr-x 1 root root 73117 Mar 15 22:16 /usr/bin/sff-dump.2 -rwxr-xr-x 1 root root 73117 Mar 15 22:16 /usr/bin/sff-dump.2.1.9 -rw-r--r-- 1 root root 62612 Mar 15 22:16 /usr/lib64/libwsradb.a -rw-r--r-- 1 root root 62612 Mar 15 22:16 /usr/lib64/libwsradb.a.3 -rw-r--r-- 1 root root 62612 Mar 15 22:16 /usr/lib64/libwsradb.a.3.1.4 -rwxr-xr-x 1 root root 470020 Mar 15 22:16 /usr/lib64/libwvdb.so -rwxr-xr-x 1 root root 470020 Mar 15 22:16 /usr/lib64/libwvdb.so.2 -rwxr-xr-x 1 root root 470020 Mar 15 22:16 /usr/lib64/libwvdb.so.2.2.5 #
The answer to your original question is quite simple: - doins supports symbolic links in EAPI 4. - dobin doesn't support symbolic links. And I don't see where the devmanual would claim otherwise. (In reply to comment #1) > Neither "dolib" nor "dosym -r lib/*" transfer symlinks correctly. dolib should preserve relative symlinks in the same directory. If it doesn't, then you should file a Portage bug. But what is "dosym -r" supposed to do? The dosym command doesn't accept any options. > >>> Installing (1 of 1) sci-biology/sra_sdk-2.1.9 > /sbin/ldconfig: /usr/lib64/libvdb.so.2 is not a symbolic link > [...] I don't see any dolib or dosym in that ebuild, but only the following line: for f in "${WORKDIR}"/objdir/linux/rel/gcc/"${builddir}"/lib/*; do cp --preserve=all "$f" "${D}"/usr/lib64/ || die "$f copying failed" ; done So how is this related to this bug?
(In reply to comment #2) > The answer to your original question is quite simple: > - doins supports symbolic links in EAPI 4. > - dobin doesn't support symbolic links. > And I don't see where the devmanual would claim otherwise. Yes, but that is what is not clear and I propose you to add few lines describing/explaining that. ;-) > > (In reply to comment #1) > > Neither "dolib" nor "dosym -r lib/*" transfer symlinks correctly. > > dolib should preserve relative symlinks in the same directory. If it > doesn't, then you should file a Portage bug. Would you please verify that on the mentioned ebuild? (read further) Why dobin does NOT preserve symlinks if dolib DOES? I want both to preserve them. Even into other directories, like ../blah/$sometarget. It could be configurable, no problem with me. ;) > > But what is "dosym -r" supposed to do? The dosym command doesn't accept any > options. Sorry, my typo, "doins -r", as devmanual says. > > > >>> Installing (1 of 1) sci-biology/sra_sdk-2.1.9 > > /sbin/ldconfig: /usr/lib64/libvdb.so.2 is not a symbolic link > > [...] > > I don't see any dolib or dosym in that ebuild, but only the following line: > > for f in "${WORKDIR}"/objdir/linux/rel/gcc/"${builddir}"/lib/*; do cp > --preserve=all "$f" "${D}"/usr/lib64/ || die "$f copying failed" ; done > > So how is this related to this bug? Just remove the comments on the below lines and remove those two lines with the for loop, which aimed to get around the symlink problem: 77 #insinto /usr/bin 78 #doins -r "${WORKDIR}"/objdir/linux/rel/gcc/"${builddir}"/bin/* 93 #insinto /usr/lib64 94 #dolib "${WORKDIR}"/objdir/linux/rel/gcc/"${builddir}"/lib/*
(In reply to comment #3) > > dolib should preserve relative symlinks in the same directory. If it > > doesn't, then you should file a Portage bug. > > Would you please verify that on the mentioned ebuild? (read further) Sorry, but bugzilla is neither a forum nor a helpdesk. If you claim that dolib doesn't work as intended, then it's your task to construct a minimal example demonstrating the failure and file it as a Portage bug. (Besides, I tried testing your ebuild, but I get a fetch failure ...)
