[apparmor] [patch 01/13] parser - build against in-tree libapparmor

John Johansen john.johansen at canonical.com
Sat Oct 12 02:51:12 UTC 2013


On 10/11/2013 06:34 PM, John Johansen wrote:
> On 10/10/2013 06:25 PM, Steve Beattie wrote:
>> On Thu, Oct 10, 2013 at 03:33:19PM -0700, John Johansen wrote:
>>> On 10/10/2013 01:46 PM, Steve Beattie wrote:
>>>> With trunk commit 2205 "use libapparmor's find mountpoint fn",
>>>> the parser now builds against and uses libapparmor at runtime. However,
>>>> it currently builds against the system installed libapparmor library and
>>>> header files, which fails if either aren't installed, and is thus
>>>> painful for bootstrapping in a new environment.
>>>>
>>>> Instead, the parser, like pam_apparmor and mod_apparmor, should build
>>>> against the in-tree libapparmor header and library. This patch does
>>>> that and adjusts the tests to point LD_LIBRARY_PATH at the location
>>>> of the built library as well.
>>>>
>>>> Signed-off-by: Steve Beattie <steve at nxnw.org>
>>>
>>> NAK
>>>
>>> at least in the current form, this really breaks me. The idea is good
>>> but for dev purposes I am often building the parser where I have a
>>> library that won't build.
>>
>> Do you commonly break the apparmor.h header in libapparmor?
> 
> uhhm yes it can sit broken or wrong for weeks/months. I tend to keep
> multiple patches staged and push/pop pull up and down the stack.
> 
> I probably should create new branches but, it is a real pain. /me
> doesn't like working in bzr and creating new branches that way, and
> branches are problematic in git when using git-bzr-ng
> 
In which case I guess its reasonable to just ask me to rearrange my
patch queue to move the broken/half finished patches to later on so
I with draw my objection




More information about the AppArmor mailing list