mozconfig-v6.44.eclass introduce new USE flag system-libevent, but version requirements are not consistent. First, Firefox source code comes with stable version of libevent library (firefox-xy.z.source.tar.xz:ipc/chromium/src/third_party/libevent) and it is used if 'system-libevent' USE flag is not set. Should we remove dev-libs/libevent from RDEPEND or at least bump version to stable available in portage tree? https://github.com/gentoo/gentoo/blob/master/eclass/mozconfig-v6.44.eclass#L78 # equery list -p dev-libs/libevent * Searching for libevent in dev-libs ... [-P-] [ ] dev-libs/libevent-2.0.22:0 [IP-] [ ] dev-libs/libevent-2.0.22-r2:0/2.0-5 [-P-] [ ] dev-libs/libevent-2.1.5:0 [-P-] [ ] dev-libs/libevent-2.1.5-r3:0/2.1-5 [-P-] [ ] dev-libs/libevent-2.1.5-r4:0/2.1-5 [-P-] [ -] dev-libs/libevent-9999:0 Second, propose to use SLOT dependency instead of wildcard match: -system-libevent? ( =dev-libs/libevent-2.0* ) +system-libevent? ( dev-libs/libevent:0/2.0-5 ) https://github.com/gentoo/gentoo/blob/master/eclass/mozconfig-v6.44.eclass#L117 Reproducible: Always Steps to Reproduce: N/A
Slot operator dep will be added in time for the next revision or version, I've already added it to the eclass on mozilla-overlay I'm not following your point on the rest of it though -- If firefox isn't working with system libevent-2.1* , then the solution to this is to patch the sources to make it work, not to limit the package atom installed at the system level. Please provide build.log's appropriately so that we can figure out what needs to be done.
(In reply to Ian Stakenvicius from comment #1) > Slot operator dep will be added in time for the next revision or version, > I've already added it to the eclass on mozilla-overlay > > I'm not following your point on the rest of it though -- If firefox isn't > working with system libevent-2.1* , then the solution to this is to patch > the sources to make it work, not to limit the package atom installed at the > system level. Please provide build.log's appropriately so that we can > figure out what needs to be done. Patching it would not be correct, the entire api has changed, hell even libevent-2.1 is beta software and not final. It should not have been installed add to the tree under deception.
Good to know that SLOT dep is in TODO and will be in tree soon. There are two major cases: without system-libevent and with system-libevent USE flag enabled. In latter case dep will be dev-libs/libevent:0/2.0-5 and looks reasonable. If we do not set system-libevent USE flag then version requirement looks odd '>=dev-libs/libevent-1.4.7'. I see several possible solutions: 1. Follow Firefox in-source libevent version [2.0.21-stable (18 Nov 2012)] (which comes with some additional patches according to README) firefox-44.0.source.tar.xz:firefox-44.0/ipc/chromium/src/third_party/libevent/{ChangeLog,README.mozilla} 2. Define dep to current stable dev-libs/libevent available in portage tree. 3. Remove dep from dev-libs/libevent if system-libevent USE is not set.
OK, so, first off -- version requirements don't have to be consistent in RDEPEND when there are multiple atoms for the same package. In fact, when that is the case then it is often expected that the atoms will be different. The 'system-libevent' atom of libevent-2.0* will correctly peg the system lib to the correct version. Further, the generic libevent atom will ensure libevent is installed, and a slot operator dep on that atom will ensure that changes to the subslot of the installed libevent package will trigger a rebuilt of firefox. Now, based on what i just built when system-libevent is off, it looks like firefox doesn't actually link to libevent at all. I expect then it is safe to remove the libevent atom that isn't wrapped by the system-libevent use flag, so I'll be doing that shortly unless Anarchy knows something I don't?
(In reply to Ian Stakenvicius from comment #4) > Now, based on what i just built when system-libevent is off, it looks like > firefox doesn't actually link to libevent at all. I expect then it is safe > to remove the libevent atom that isn't wrapped by the system-libevent use > flag, so I'll be doing that shortly unless Anarchy knows something I don't? That is correct it does need to be removed, appears I overlooked it when I initially made the change.
(In reply to Jory A. Pratt from comment #5) > (In reply to Ian Stakenvicius from comment #4) > > Now, based on what i just built when system-libevent is off, it looks like > > firefox doesn't actually link to libevent at all. I expect then it is safe > > to remove the libevent atom that isn't wrapped by the system-libevent use > > flag, so I'll be doing that shortly unless Anarchy knows something I don't? > > That is correct it does need to be removed, appears I overlooked it when I > initially made the change. (In reply to overlay commit 1ef28065e2) > - system-libevent? ( =dev-libs/libevent-2.0* ) > + system-libevent? ( dev-libs/libevent:0/2.0-5 ) I'm still leery of setting the full subslot value here as the limiting factor. If a new 2.0-series ABI is released then we'll keep it from upgrading; alternatively if the subslot format changes then end-users can't just rebuild to get the new one in their VDB, we'll have to change the atom and revbump all the packages... Is there anything wrong with =dev-libs/libevent-2.0*:= as the atom?
If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system. Thank You for your support and understanding The Mozilla Team
