| Summary: | www-plugins/adobe-flash: please consider reusing abi_x86_* flags | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
| Component: | Current packages | Assignee: | Jeroen Roovers (RETIRED) <jer> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bertrand, desktop-misc, mmk, multilib+disabled |
| Priority: | Normal | Keywords: | PATCH |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 454644 | ||
| Attachments: |
adobe-flash-11.2.202.310.ebuild.diff
Ebuild r1 |
||
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. |
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.