[apparmor] [PATCH 4/6] libapparmor: Check for podchecker during configure stage
Steve Beattie
steve at nxnw.org
Mon Nov 17 22:33:38 UTC 2014
On Mon, Nov 17, 2014 at 03:05:19PM -0600, Tyler Hicks wrote:
> Fail the configure stage if podchecker is not available since man page
> generation always happens.
I think I disagree with this patch and the first patch. The minimal
bit of userspace tools you need to get apparmor going in a limited
environment are the libapparmor C library and the parser. I grant
that we don't necessarily make it straightforward to build only these
things, but requiring that some portion of perl be available at build
time feels wrong to me.
That said, I realize we already require pod2man as part of the
libapparmor build; that check should probably also be conditional on
having perl available as well.
But I'm not in any way knowledgeable about bringing up embedded or
otherwise limited environments, so maybe expecting that people have
access to perl/pod2man/podchecker is reasonable. We have tried to fix
problems that occurred when cross-compiling for embedded environments,
and I think we should continue to support (and improve our support for)
such environments.
I wouldn't mind if we made --with-python a default setting and
then supported --without-python (or --no-with-python or whatever
the configure idiom is for stuff like that). Perhaps similarly for
--with-perl, too, though it's pretty clear going forward the perl
bindings to libapparmor are going to be less well-exercised than the
python bindings. And it's perhaps the case that I'm conflating 'have
perl' with 'build the perl bindings', so there's that consideration,
too.
And, it was mentioned that --with-or-without-perl doesn't apply across
the rest of the tree; that's true mostly out of a resistance to use
autotools for the rest of the tree, though I do have a TODO task
to look at resurrecting Kees' patch for that, and perhaps compare
with what cmake provides. There are a lot of times, however, where
we do things that feel like fitting square pegs into round autotools
holes, particularly around tests and building against multiple python
versions. A lot of automake's support for tests seems to come down
to 'we'll run whatever single test script you want', and finding
out things like 'where the libapparmor python binding library build
ended up, so that I can point test scripts at it' don't seem to be
easily discoverable.
--
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/20141117/dd97adcd/attachment.pgp>
More information about the AppArmor
mailing list