[apparmor] [RFC] [patch] Makefile automatically fallback to USE_SYSTEM=1

[Steve Beattie]

On Tue, Mar 11, 2014 at 12:22:19PM -0700, John Johansen wrote:
> On 03/11/2014 11:52 AM, Steve Beattie wrote:
> > I'm still mulling/trying to remember the arguments from when we added
> > USE_SYSTEM so I don't have a yay or nay on this patch.
> 
> I don't remember it either, but I am finding the current behavior a
> major annoyance. This or something like it doesn't have to make it
> upstream but I will continue to use it, which is why the RFC.

Alright, I've refreshed my memory. Initially, I had implemented
the behavior you wanted, except that I did it poorly because the
in-tree apparmor.h header would always be found and used; however,
if the library wasn't built, then the system one would be used. It
was rightly pointed out that having a mismatch of header to library
was setting up someone for a bad failure.

Others have argued that the fallback behavior is dangerous even if
implemented correctly. I'm not entirely convinced of that, but I
will continue to strenuously argue that using the in-tree library
is the safer and preferred option, and depending on the age of the
libapparmor on the platform you're building on, you may suffer from
compilation failures (for example, trunk parser fails to compile
against the libapparmor provided by Ubuntu 13.10).

On Tue, Mar 11, 2014 at 12:27:27PM -0700, John Johansen wrote:
> On 03/09/2014 09:36 AM, Christian Boltz wrote:
> > I understand why you like this behaviour, but I don't like it too much 
> > because it introduces some "surprising" behaviour. (And I doubt someone 
> > reads the warning if the test succeeds ;-)
> > 
> I'm not sure why its a surprising behavior, but okay. Question is who
> do you see the consumer as?

We have multiple consumers: developers (like you and me), distribution
packagers (who may or may not be following bikeshedding discussions
about build behavior and build ordering), and end users (who
have similar issues as distributors, though granted an end user is
typically pulling our tarball because their platform doesn't provide
apparmor, so there's no system libapparmor to build against to
begin with).  It's definitely not out of the realm of possibilities
for a distribution packager to not build stuff in the right order
(i.e. not build libapparmor first), such that some things get built
with the system libapparmor.

> > Thinking about it - can you implement an additional condition like 
> > "file common/enable-auto-fallback-to-USE_SYSTEM exists" (or an 
> > environment variable you set in .bashrc, but a file sounds better)?
> > 
> > That would mean people have to actively opt-in to the automatical 
> > fallback by touch'ing the file once in their bzr checkout. This would 
> > fix the "surprise" part.
> > 
> > With the opt-in file added, the patch looks good to me.
> > 
> using a file is possible, but how about opt-out instead? It would be
> easy to add USE_SYSTEM=0, to opt-out. So if USE_SYSTEM is defined
> (either 0 or 1) you get one or the other behavior other wise it tries
> to build against one then the other

Are you intending this behavior for just the regression tests or for
everywhere in the tree that libapparmor is made use of?

I'm okay with this approach (particularly since I already tried to
implement fallback behavior once poorly), so long as a warning is
given if falling back. And if your intended scope is across the tree,
that we encourage distros to build with USE_SYSTEM=0 in addition to
the VERBOSE=1 we already recommend.

In any event, all of this serves as a reminder to be careful with
the libapparmor ABI/API.

-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20140311/342c7146/attachment.pgp>