Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 409261 - app-arch/xz-utils: avoid shell glob when seeking libtool archive to delete
Summary: app-arch/xz-utils: avoid shell glob when seeking libtool archive to delete
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal trivial (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords: EBUILD, PATCH
Depends on:
Blocks:
 
Reported: 2012-03-22 03:38 UTC by Kevin Pyle
Modified: 2012-05-17 04:05 UTC (History)
0 users

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


Attachments
Patch to xz-utils-5.0.3.ebuild to avoid use of a shell glob when deleting liblzma.la (xz-utils-5.0.3.ebuild.patch,494 bytes, patch)
2012-03-22 03:38 UTC, Kevin Pyle
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Pyle 2012-03-22 03:38:45 UTC
Created attachment 306257 [details, diff]
Patch to xz-utils-5.0.3.ebuild to avoid use of a shell glob when deleting liblzma.la

In app-arch/xz-utils-5.0.3, the latest stable as of this writing, src_install() uses 'rm "${D}"/usr/*/liblzma.la' to delete the unwanted libtool archive.  This assumes that a shell glob of * will match the library directory.  That assumption holds on typical profiles, but is not guaranteed.  I am experimenting with a multiarch aware layout (LWN article about Debian multiarch: <http://lwn.net/Articles/482952/>), where LIBDIR_amd64=lib/x86_64-linux-gnu.  Thus, for me, the glob fails because libdir is two levels deep, not one.  The attached patch switches to "${D}"/usr/$(get_libdir)/liblzma.la, which fixes this deletion for the multiarch case and still works correctly for standard systems.  Since this is purely a build-time issue, no revbump is needed.
Comment 1 Samuli Suominen (RETIRED) gentoo-dev 2012-03-22 13:01:51 UTC
many, many ebuilds use `rm "${D}"/usr/lib*/lib*.la` which seems to be working fine. are you saying they are all wrong? never seen it fail here.
$get_libdir is overkill here.
Comment 2 Kevin Pyle 2012-03-23 03:10:50 UTC
I am saying that they are only correct when ${LIBDIR_${ABI}} contains no slashes.  In-tree profiles happen to satisfy this assumption.  However, the multiarch layout of using /usr/lib/$CHOST/ violates that assumption.  The ebuild in question already inherits multilib.eclass and uses get_libdir elsewhere, so I do not think it is overkill to use it one more time in the ebuild.  Once multilib.eclass has been inherited, individual calls to get_libdir look cheap.  I agree that adding multilib.eclass just for this could be considered excessive.

With regard to "many ebuilds":
$ grep -r 'rm.*/lib\*/' /usr/portage/*/*/*.ebuild | wc
    196    1006   19502
$ grep -rl 'rm.*/lib\*/' /usr/portage/*/*/*.ebuild | sed -e 's:/[^/]*$::' | uniq | wc
    120     120    3946

However, since the failure only occurs when building with an unusual $LIBDIR, the problem can only affect new builds, so only the newest ebuild of a given package would need to be adjusted.  For at least some of the ebuilds matched by that grep, the expression matches only in an older ebuild, so the entire package can be excluded.
Comment 3 SpanKY gentoo-dev 2012-05-17 04:05:31 UTC
should be all set now in the tree; thanks for the report!

Commit message: Use `find` to clean up .la file
http://sources.gentoo.org/app-arch/xz-utils/xz-utils-5.0.3.ebuild?r1=1.10&r2=1.11
http://sources.gentoo.org/app-arch/xz-utils/xz-utils-9999.ebuild?r1=1.10&r2=1.11