package/refpolicy: do not use the bare target in the configuration step

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(-)

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