net-wireless/bluez ebuilds starting with 4.91 have a bug. Apparently, since EAPI 4, newins and doins preserve symlinks. The file oui.txt is installed as follows: insinto /var/lib/misc newins "${DISTDIR}/oui-${OUIDATE}.txt" oui.txt However, "${DISTDIR}/oui-${OUIDATE}.txt" is a symlink: /var/tmp/portage/net-wireless/bluez-4.91/distdir/oui-20110330.txt -> /usr/portage/distfiles/oui-20110330.txt So the symlink itself is copied, and the result is /var/lib/misc/oui.txt -> /usr/portage/distfiles/oui-20110330.txt
Installed file is ok for me: # ls -l /var/lib/misc/oui.txt -rw-r--r-- 1 root root 2372550 jun 8 12:32 /var/lib/misc/oui.txt
Maybe it depends on portage version; mine is latest stable - 2.1.9.42.
/usr/lib/portage/bin/ebuild-helpers/doins: case "$EAPI" in 0|1|2|3|3_pre2) PRESERVE_SYMLINKS=n ;; *) PRESERVE_SYMLINKS=y ;; esac if [ -L "$mysrc" ] ; then if [ $PRESERVE_SYMLINKS = y ] ; then rm -rf "$D$INSDESTTREE/$mydir/${mysrc##*/}" || return $? cp -P "$mysrc" "$D$INSDESTTREE/$mydir/${mysrc##*/}" return $? else /usr/lib/portage/bin/ebuild-helpers/newins: case "$EAPI" in 0|1|2|3|3_pre2) cp "$1" "$T/$2" || exit $? ;; *) cp -P "$1" "$T/$2"
I cannot reproduce this with sys-apps/portage-2.1.9.50
This is fixed since portage-2.1.9.46: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=de9a536f470919651e83ece51923594e8605781b
When will a fixed portage version hit stable to prevent issues like this? Thanks :-)
(In reply to comment #5) > This is fixed since portage-2.1.9.46: Great - I was searching in vain for a relevant bug in the depends list of #358927.
(In reply to comment #6) > When will a fixed portage version hit stable to prevent issues like this? > Thanks :-) The plan is for portage-2.1.10 to be stabilized in approximately 30 days.
(In reply to comment #6) > When will a fixed portage version hit stable to prevent issues like this? Maybe it's easier to downgrade the required EAPI to 3 in the meanwhile? "diff /usr/portage/net-wireless/bluez/bluez-4.{87,91}.ebuild" doesn't seem to show anything EAPI 4-specific. As it stands, installing bluez on a stable system produces incorrect results. Some users regularly purge /usr/portage/distfiles.
Or maybe install that file with "cp" instead of "newins" until this is solved in stable... not sure how to proceed as this wrong portage behavior is probably causing more problems like this (that will need a recompilation to get solved!) for any other packages using this :-/ Couldn't portage team release a new portage version fixing only this bug and fast-stabilize it?
(In reply to comment #9) > Maybe it's easier to downgrade the required EAPI to 3 in the meanwhile? "diff > /usr/portage/net-wireless/bluez/bluez-4.{87,91}.ebuild" doesn't seem to show > anything EAPI 4-specific. Alternatively, de-reference the symlink manually. It seems that the bluez-4.93 ebuild is already doing this since it unpacks oui-${OUIDATE}.txt.xz into $WORKDIR and then installs the txt file from there. (In reply to comment #10) > Or maybe install that file with "cp" instead of "newins" until this is solved > in stable... not sure how to proceed as this wrong portage behavior is probably > causing more problems like this (that will need a recompilation to get solved!) > for any other packages using this :-/ Well, you could just stabilize bluez-4.93 since it's already been in the tree for more than 30 days. > Couldn't portage team release a new portage version fixing only this bug and > fast-stabilize it? Well, it doesn't seem worth the trouble given that it doesn't affect many ebuilds and there's an easy workaround.
(In reply to comment #0) [...] > insinto /var/lib/misc > newins "${DISTDIR}/oui-${OUIDATE}.txt" oui.txt [...] Can you check if using "WORKDIR" instead of "DISTDIR" improves the situation?
(In reply to comment #11) > Well, you could just stabilize bluez-4.93 since it's already been in the tree > for more than 30 days. > It's true, for some reason I though I added it more recently ;), will go for this solution then
(In reply to comment #12) > (In reply to comment #0) > [...] > > insinto /var/lib/misc > > newins "${DISTDIR}/oui-${OUIDATE}.txt" oui.txt > [...] > > Can you check if using "WORKDIR" instead of "DISTDIR" improves the situation? You'd have to add something like this: cp "${DISTDIR}/oui-${OUIDATE}.txt" "${WORKDIR}/oui-${OUIDATE}.txt" It's not necessary in the bluez-4.93 ebuild since it's compressed to a txt.xz file and unpack() automatically unpacks that into $WORKDIR.
Well, the bug is not fixed after all ATM - oui.txt installs as a symlink on a stable system.
(In reply to comment #12) > Can you check if using "WORKDIR" instead of "DISTDIR" improves the situation? This works: cp "${DISTDIR}/oui-${OUIDATE}.txt" "${WORKDIR}/oui-${OUIDATE}.txt" newins "${WORKDIR}/oui-${OUIDATE}.txt" oui.txt
bluez-4.93 is now stable for the same archs that bluez-4.91 is stable, so this bug is no more relevant.
