Pacho Ramos <[email protected]> said: > Hello > > Let my explain the problem and my suggestion to handle it better (at > least from my point of view) with an example: > > Sometime ago I bumped bluez version from 4.39-r2 to 4.60, with that > bump, a new and *optional* RDEPEND on sys-libs/libcap-ng was added. > Since libcap-ng was not keyworded in all arches but x86 and amd64, I > had to drop keywords for bluez and open > http://bugs.gentoo.org/show_bug.cgi?id=303527 for handling it. > > From my point of view, I would prefer to: > 1. Mask "caps" for net-wireless/bluez on affected arches, letting us to > keep bluez keyworded. > 2. Open two bug reports as done with current policy: one for keywording > libcap-ng and other to check bluez works ok with it asking arch team to > unmask that USE flag if possible. > > This way to go would have the advantage of letting people running bluez > on affected arches to still get the latest bluez version instead of > still having to run a pretty old (and buggy) one.
it seems to depend on turnaround time. if arch teams respond quickly, then the USE flag masking would just be an increase in workload. if they are slow to respond then that may be a good investment. given that one cant dictate the speed at which arch teams work, your proposal sounds very sensible. I am OK with both methods. kind regards Thilo > > Thanks for considering it
signature.asc
Description: This is a digitally signed message part.
