> On Wed, 15 Apr 2020, Matt Turner wrote:
>> This is a CBUILD type dependency, right? Then there is no good way to
>> express it in EAPI 7. Still, I think that it should be specified in
>> BDEPEND (and maybe RDEPEND in addition).
> I'm not sure what CBUILD means. What is that?
That's a depen
On Wed, Apr 15, 2020 at 6:44 AM David Michael wrote:
>
> On Tue, Apr 14, 2020 at 10:32 PM Matt Turner wrote:
> > At the same time, fix the dependency on sys-libs/libcap by moving it to
> > RDEPEND, as dependencies in DEPEND/BDEPEND are not guaranteed to exist
> > during pkg_postinst() when this
On Wed, Apr 15, 2020 at 1:37 AM Ulrich Mueller wrote:
>
> > On Wed, 15 Apr 2020, Matt Turner wrote:
>
> > At the same time, fix the dependency on sys-libs/libcap by moving it to
> > RDEPEND, as dependencies in DEPEND/BDEPEND are not guaranteed to exist
> > during pkg_postinst() when this ecla
On Tue, Apr 14, 2020 at 10:32 PM Matt Turner wrote:
> At the same time, fix the dependency on sys-libs/libcap by moving it to
> RDEPEND, as dependencies in DEPEND/BDEPEND are not guaranteed to exist
> during pkg_postinst() when this eclass is intended to run.
The BDEPEND was added for https://bu
> On Wed, 15 Apr 2020, Matt Turner wrote:
> At the same time, fix the dependency on sys-libs/libcap by moving it to
> RDEPEND, as dependencies in DEPEND/BDEPEND are not guaranteed to exist
> during pkg_postinst() when this eclass is intended to run.
This is a CBUILD type dependency, right? T
libcap-ng-0.7.10 changed the output format slightly (in upstream commit
bc1a9c07ebf5 "- Add capng_have_permitted_capabilities function and use
it in filecap"), breaking our usage of it. It's obvious that it's not
supposed to be used programmatically given the awful sed'ing we were
already doing. It
