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(-)
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
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.
quoted hunk
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 at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
Hi Yann,
Quoting Yann E. MORIN (2021-02-10 21:47:59)
On 2021-02-10 19:51 +0100, Antoine Tenart spake thusly:
quoted
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)
quoted
On 2021-02-10 19:51 +0100, Antoine Tenart spake thusly:
quoted
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.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
Quoting Yann E. MORIN (2021-02-11 18:31:18)
On 2021-02-11 09:51 +0100, Antoine Tenart spake thusly:
quoted
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 :)
quoted
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