version bump for asterisk-g729 to include asterisk-10.0 support. Reproducible: Always
Created attachment 297303 [details] asterisk-10.0.3.1.5.ebuild
Jaco, I guess you should inherit multilib and edit your insinto line
Agostino, I've read through the multilib eclass and don't see how it applies. The ONLY software for which this is useful is for asterisk, thus on a 64-bit system the 64-bit variant will be downloaded and installed, on a 32-bit system the 32-bit version will be downloaded and installed. Please also see bug 396413 for why I use doins instead of the dolib.so or dolib eclass wrapper functions. Boils down to: asterisk simply won't work if the .so is anywhere other than /usr/lib/asterisk/modules. On a 32-bit install there is only /usr/lib/, on a 64-bit (amd64 at least) /usr/lib is a symlink to /usr/lib64 ... so I honestly don't see the problem. Basically if I follow you are suggesting to replace: insinto usr/lib/asterisk/modules with: insinto usr/$(get_libdir)/asterisk/modules ? If so that is a change I can make but don't think I quite understand why this is required... would you mind enlightening me please?
(In reply to comment #3) > If so that is a change I can make but don't think I quite understand why this > is required... would you mind enlightening me please? Files matching a file type that is not allowed: usr/lib/asterisk/modules/codec_g729a.so * ERROR: net-misc/asterisk-g729-10.0.3.1.5 failed: * multilib-strict check failed! Is this enough?
Created attachment 297365 [details] asterisk-10.0.3.1.5.ebuild Yes it is. I'd still like to know WHAT it checks for and understand the motivation behind that check if it's not too much to ask. Kind Regards,
(In reply to comment #5) > I'd still like to know WHAT it checks for and understand the motivation behind > that check if it's not too much to ask. On sufficiently old multilib installs /usr/lib is not a symlink; it is a directory. This can result in /usr/lib, /usr/lib32 & /usr/lib64 all existing, with different contents. The resulting bugs can be downright maddening, and as such we can not and do not trust the /usr/lib symlink to be valid. Doing so (which you are, currently) is a "multilib-strict" bug.
(In reply to comment #6) > (In reply to comment #5) > > I'd still like to know WHAT it checks for and understand the motivation behind > > that check if it's not too much to ask. > > On sufficiently old multilib installs /usr/lib is not a symlink; it is a > directory. This can result in /usr/lib, /usr/lib32 & /usr/lib64 all existing, > with different contents. > The resulting bugs can be downright maddening, and as such we can not and do > not trust the /usr/lib symlink to be valid. Doing so (which you are, currently) > is a "multilib-strict" bug. Perfect explanation thank you very much. Is the ebuild as I've updated it OK now? How can I enable that particular check on my own system for future testing?
(In reply to comment #7) > Is the ebuild as I've updated it OK now? How can I enable that particular > check on my own system for future testing? Yes, you have inherited multilib so get_libdir is available. Easiest way to get to "security level ago" is switching to the developer profile using eselect. It is probably enabled at a lower level through FEATURES, either strict or stricter.
+*asterisk-g729-10.0.3.1.5 (03 Jan 2012) + + 03 Jan 2012; Tony Vroon <chainsaw@gentoo.org> + +asterisk-g729-10.0.3.1.5.ebuild: + Version bump, ebuild by Jaco Kroon with input from Agostino "ago" Sarubbo. + Closes bug #396415.
