Message ID | 20210210185158.1254415-1-atenart@kernel.org |
---|---|
State | Rejected |
Headers | show |
Series | package/refpolicy: do not use the bare target in the configuration step | expand |
Antoine, All, On 2021-02-10 19:51 +0100, Antoine Tenart spake thusly: > The 'bare' target is a clean target, removing generated files from > previous builds. Here in Buildroot we'll only build the refpolicy from a > clean state and we don't need to execute this target. Remove it. Will that still do correct builds with 'make refpolicy-rebuild' ? Regards, Yann E. MORIN. > Signed-off-by: Antoine Tenart <atenart@kernel.org> > --- > package/refpolicy/refpolicy.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/package/refpolicy/refpolicy.mk b/package/refpolicy/refpolicy.mk > index 0194708b378d..62d96e68043c 100644 > --- a/package/refpolicy/refpolicy.mk > +++ b/package/refpolicy/refpolicy.mk > @@ -108,7 +108,7 @@ define REFPOLICY_CONFIGURE_CMDS > $(if $(REFPOLICY_EXTRA_MODULES_DIRS), \ > $(REFPOLICY_COPY_EXTRA_MODULES) > ) > - $(REFPOLICY_MAKE) -C $(@D) bare conf > + $(REFPOLICY_MAKE) -C $(@D) conf > $(REFPOLICY_CONFIGURE_MODULES) > endef > > -- > 2.29.2 > > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Hi Yann, Quoting Yann E. MORIN (2021-02-10 21:47:59) > On 2021-02-10 19:51 +0100, Antoine Tenart spake thusly: > > The 'bare' target is a clean target, removing generated files from > > previous builds. Here in Buildroot we'll only build the refpolicy from a > > clean state and we don't need to execute this target. Remove it. > > Will that still do correct builds with 'make refpolicy-rebuild' ? I think you meant refpolicy-reconfigure, as I don't think rebuild will call the configuration step again. I double checked and there's an issue with an use case; the list of modules to compile is not updated if a module is deleted (if added, yes...). While we shouldn't expect much when deleting something from a package (as the installation step will not clean what was installed before), here, as we're explicitly using the monolithic build, removing a module and reconfiguring should work. So let's be safe and keep this as is. Thanks! Antoine
Antoine, All, On 2021-02-11 09:51 +0100, Antoine Tenart spake thusly: > Quoting Yann E. MORIN (2021-02-10 21:47:59) > > On 2021-02-10 19:51 +0100, Antoine Tenart spake thusly: > > > The 'bare' target is a clean target, removing generated files from > > > previous builds. Here in Buildroot we'll only build the refpolicy from a > > > clean state and we don't need to execute this target. Remove it. > > > > Will that still do correct builds with 'make refpolicy-rebuild' ? > > I think you meant refpolicy-reconfigure, as I don't think rebuild will > call the configuration step again. Yes, of course. ;-) > I double checked and there's an issue with an use case; the list of > modules to compile is not updated if a module is deleted (if added, > yes...). While we shouldn't expect much when deleting something from a > package (as the installation step will not clean what was installed > before), Well, it can happen if one is using on a custom policy and working on it with REFPOLICY_OVERRIDE_SRCDIR: the source files may change, appear, or disappear between two builds... > here, as we're explicitly using the monolithic build, removing > a module and reconfiguring should work. So let's be safe and keep this > as is. So I've marked this patch as rejected in patchwork, then. Thanks for the prompt feedback! Regards, Yann E. MORIN.
Quoting Yann E. MORIN (2021-02-11 18:31:18) > On 2021-02-11 09:51 +0100, Antoine Tenart spake thusly: > > > I double checked and there's an issue with an use case; the list of > > modules to compile is not updated if a module is deleted (if added, > > yes...). While we shouldn't expect much when deleting something from a > > package (as the installation step will not clean what was installed > > before), > > Well, it can happen if one is using on a custom policy and working on it > with REFPOLICY_OVERRIDE_SRCDIR: the source files may change, appear, or > disappear between two builds... Depends on what the output of the build is :) > > here, as we're explicitly using the monolithic build, removing > > a module and reconfiguring should work. So let's be safe and keep this > > as is. > > So I've marked this patch as rejected in patchwork, then. Thanks for the > prompt feedback! Thanks! Antoine
diff --git a/package/refpolicy/refpolicy.mk b/package/refpolicy/refpolicy.mk index 0194708b378d..62d96e68043c 100644 --- a/package/refpolicy/refpolicy.mk +++ b/package/refpolicy/refpolicy.mk @@ -108,7 +108,7 @@ define REFPOLICY_CONFIGURE_CMDS $(if $(REFPOLICY_EXTRA_MODULES_DIRS), \ $(REFPOLICY_COPY_EXTRA_MODULES) ) - $(REFPOLICY_MAKE) -C $(@D) bare conf + $(REFPOLICY_MAKE) -C $(@D) conf $(REFPOLICY_CONFIGURE_MODULES) endef
The 'bare' target is a clean target, removing generated files from previous builds. Here in Buildroot we'll only build the refpolicy from a clean state and we don't need to execute this target. Remove it. Signed-off-by: Antoine Tenart <atenart@kernel.org> --- package/refpolicy/refpolicy.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)