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 <[email protected]> http://NxNW.org/~steve/
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
