Since the abi_x86_{32,64} flags are getting well-known, and properly controlled in profiles, I think adobe-flash would benefit from reusing them. If you need, I can try to wrap up a patch for the current ebuild.
Patches are welcome! :)
I find it hard to read adobe-flash deps. 1. is emul-linux-x86-baselibs omitted because it is a dep of gtklibs/soundlibs? I see nspr, nss & curl in native deps which AFAIR are part of that. 2. same for -xlibs? that would count fontconfig. 3. why is -soundlibs in emul dep and no sound library in native deps? While changing the flags, I would like to replace the deps to support multilib ebuilds as well. Then emul deps would look like || ( emul-linux... ( package1[abi_x86_32(-)] ... ) ).
(In reply to Michał Górny from comment #2) > I find it hard to read adobe-flash deps. Two things I should probably point out: I have no systems that support multilib, and I only recently took over adobe-flash maintenance. If you find anything wrong with its multilib support dependencies, then start fixing those right now (particularly in -r1, but in the stable ebuild as well if you think it's safe) before you even begin to improve the ebuilds as per this bug report. > While changing the flags, I would like to replace the deps to support > multilib ebuilds as well. Then emul deps would look like || ( emul-linux... > ( package1[abi_x86_32(-)] ... ) ). Sure.
(In reply to Jeroen Roovers from comment #3) > (In reply to Michał Górny from comment #2) > > I find it hard to read adobe-flash deps. > > Two things I should probably point out: I have no systems that support > multilib, and I only recently took over adobe-flash maintenance. If you find > anything wrong with its multilib support dependencies, then start fixing > those right now (particularly in -r1, but in the stable ebuild as well if > you think it's safe) before you even begin to improve the ebuilds as per > this bug report. Depends on what you call wrong. It technically works but per our QA standards, I think the deps could be improved. Specifically, since this is a binary package, I think every dependency should be listed. Do we agree in this?
(In reply to Michał Górny from comment #4) > Depends on what you call wrong. It technically works but per our QA > standards, I think the deps could be improved. Specifically, since this is a > binary package, I think every dependency should be listed. Do we agree in > this? Yes.
*** Bug 485770 has been marked as a duplicate of this bug. ***
Created attachment 359314 [details, diff] adobe-flash-11.2.202.310.ebuild.diff As from my duplicate: This patch updates the latest adobe-flash ebuild which adds missing deps, adds the possibility using pure multilib ebuild's and also enhance the ebuild in general. Major credit also goes to _AxS_!
I will probably fiddle with the ebuild a bit more and try to get it a bit cleaner. @jer, would you mind if I removed the /opt/Adobe... invention and just put stuff in /usr/lib64/nsplugins and /usr/bin? This wouldn't trigger the original bug and make the code a bit simpler.
(In reply to Michał Górny from comment #8) > I will probably fiddle with the ebuild a bit more and try to get it a bit > cleaner. The attached patch, you mean? AFAICT the run-time dependencies should have [abi_...] stuff suffixed. > @jer, would you mind if I removed the /opt/Adobe... invention and just put > stuff in /usr/lib64/nsplugins and /usr/bin? This wouldn't trigger the > original bug and make the code a bit simpler. It's not quite an invention. acroread uses the same convenient /opt/Adobe prefix. Why is /usr/$libdir necessary, again (except for a different kind of convenience)? Maybe it's worth looking at previous gentoo-dev@ discussions about why *not* using /opt is so terribly important. Some people are quite adamant about that...
(In reply to Jeroen Roovers from comment #9) > > @jer, would you mind if I removed the /opt/Adobe... invention and just put > about why *not* using /opt is so terribly important. Some people are quite s|*not*|| That is to say, if you can come up with a more convenient ebuild, then I'm all for it.
Tell you what. If you just plonk something that works for you into the tree as a revision bump, we will get enough time to work out the kinks before the next security bump & stabilisation occurs.
Created attachment 359388 [details] Ebuild r1 Not attaching a diff since it's almost completely different ebuild :). Work of me, AxS and iamnr3. The build process is completely ABI-oriented. I was able to scrap up src_unpack() that does filtering on filenames in ${A}, therefore not having to manually handle USE=debug. The install locations have been changed so that everything is installed in /usr. Alike in the current ebuild, on amd64 the programs are only installed when 64-bit ABI is enabled. However, I'm wondering if the -settings thingie shouldn't be installed unconditionally -- and if in 32-bit version when 64-bit ABI is disabled, or 64-bit in both cases. Also, AxS did some fixes to nspluginwrapper code.
Committed.
