Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 408199 - clarify whether dobin and dolib respect symlinks in EAPI=4
Summary: clarify whether dobin and dolib respect symlinks in EAPI=4
Status: UNCONFIRMED
Alias: None
Product: Documentation
Classification: Unclassified
Component: Devmanual (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Quality Assurance Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-14 19:05 UTC by Martin Mokrejš
Modified: 2012-03-15 23:30 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Mokrejš 2012-03-14 19:05:49 UTC
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.
Comment 1 Martin Mokrejš 2012-03-15 21:26:38 UTC
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
#
Comment 2 Ulrich Müller gentoo-dev 2012-03-15 22:35:47 UTC
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?
Comment 3 Martin Mokrejš 2012-03-15 23:04:38 UTC
(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/*
Comment 4 Ulrich Müller gentoo-dev 2012-03-15 23:30:53 UTC
(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 ...)