Post-image script feature and other related fixes

[Thomas Petazzoni]

Hello,

For quite a while, I had this post-image patch sitting around in one
of my customer's project, and the last mail from Stephan reminded me
that it was probably time to clean it up, update it and send it
upstream. That's the first two patches.

Then, in patches 3 and 4, I remove the package/customize stuff,
deprecated since a long time.

And in patch 5, I slightly update/improve the documentation about the
various solutions to customize the root filesystem.

Best regards,

Thomas

[Thomas Petazzoni]

Just like we have a post-build script mechanism that gets executed
after the build of all packages but before the creation of the
filesystem images, let's introduce a post-image script mechanism, that
gets executed once all filesystem images have been generated.

This can for example be used to call a tool building a firmware image
from different images generated by Buildroot, or automatically extract
the tarball root filesystem image into some location exported by NFS,
or any other custom action.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/***@public.gmane.org>
---
Makefile | 9 +++++++++
system/Config.in | 18 ++++++++++++++++++
2 files changed, 27 insertions(+)

diff --git a/Makefile b/Makefile
index 6f8ed0e..88b5a85 100644
--- a/Makefile
+++ b/Makefile
@@ -353,6 +353,8 @@ endif

include fs/common.mk

+TARGETS+=target-post-image
+
TARGETS_CLEAN:=$(patsubst %,%-clean,$(TARGETS))
TARGETS_SOURCE:=$(patsubst %,%-source,$(TARGETS) $(BASE_TARGETS))
TARGETS_DIRCLEAN:=$(patsubst %,%-dirclean,$(TARGETS))
@@ -548,6 +550,13 @@ target-generatelocales: host-localedef
done
endif

+target-post-image:
+ifneq ($(BR2_ROOTFS_POST_IMAGE_SCRIPT),)
+ @$(call MESSAGE,"Executing post-image script\(s\)")
+ @$(foreach s, $(call qstrip,$(BR2_ROOTFS_POST_IMAGE_SCRIPT)), \
+ $(s) $(BINARIES_DIR)$(sep))
+endif
+
toolchain-eclipse-register:
./support/scripts/eclipse-register-toolchain `readlink -f $(O)` $(notdir $(TARGET_CROSS)) $(BR2_ARCH)

diff --git a/system/Config.in b/system/Config.in
index 69863c4..1ffe8a0 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -265,4 +265,22 @@ config BR2_ROOTFS_POST_BUILD_SCRIPT
only argument. Make sure the exit code of those scripts are 0,
otherwise make will stop after calling them.

+config BR2_ROOTFS_POST_IMAGE_SCRIPT
+ string "Custom script to run after creating filesystem images"
+ default ""
+ help
+ Specify a space-separated list of scripts to be run after
+ the build has finished and after Buildroot has packed the
+ files into selected filesystem images.
+
+ This can for example be used to call a tool building a
+ firmware image from different images generated by Buildroot,
+ or automatically extract the tarball root filesystem image
+ into some location exported by NFS, or any other custom
+ action.
+
+ These scripts are called with the images directory name as
+ first and only argument. The script is executed from the
+ main Buildroot source directory as the current directory.
+
endmenu

[Stefan Fröberg]

Post by Thomas Petazzoni
Just like we have a post-build script mechanism that gets executed
after the build of all packages but before the creation of the
filesystem images, let's introduce a post-image script mechanism, that
gets executed once all filesystem images have been generated.
This can for example be used to call a tool building a firmware image
from different images generated by Buildroot, or automatically extract
the tarball root filesystem image into some location exported by NFS,
or any other custom action.
---
Makefile | 9 +++++++++
system/Config.in | 18 ++++++++++++++++++
2 files changed, 27 insertions(+)
diff --git a/Makefile b/Makefile
index 6f8ed0e..88b5a85 100644
--- a/Makefile
+++ b/Makefile
@@ -353,6 +353,8 @@ endif
include fs/common.mk
+TARGETS+=target-post-image
+
TARGETS_CLEAN:=$(patsubst %,%-clean,$(TARGETS))
TARGETS_SOURCE:=$(patsubst %,%-source,$(TARGETS) $(BASE_TARGETS))
TARGETS_DIRCLEAN:=$(patsubst %,%-dirclean,$(TARGETS))
@@ -548,6 +550,13 @@ target-generatelocales: host-localedef
done
endif
+ifneq ($(BR2_ROOTFS_POST_IMAGE_SCRIPT),)
+ $(s) $(BINARIES_DIR)$(sep))
+endif
+
./support/scripts/eclipse-register-toolchain `readlink -f $(O)` $(notdir $(TARGET_CROSS)) $(BR2_ARCH)
diff --git a/system/Config.in b/system/Config.in
index 69863c4..1ffe8a0 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -265,4 +265,22 @@ config BR2_ROOTFS_POST_BUILD_SCRIPT
only argument. Make sure the exit code of those scripts are 0,
otherwise make will stop after calling them.
+config BR2_ROOTFS_POST_IMAGE_SCRIPT
+ string "Custom script to run after creating filesystem images"
+ default ""
+ help
+ Specify a space-separated list of scripts to be run after
+ the build has finished and after Buildroot has packed the
+ files into selected filesystem images.
+
+ This can for example be used to call a tool building a
+ firmware image from different images generated by Buildroot,
+ or automatically extract the tarball root filesystem image
+ into some location exported by NFS, or any other custom
+ action.
+
+ These scripts are called with the images directory name as
+ first and only argument. The script is executed from the
+ main Buildroot source directory as the current directory.
+
endmenu

Nice. I know exactly what Im going to use this mechanism for.

Packing target binaries with UPX (http://upx.sourceforge.net/) at the
end of image creation.

Every byte counts :-)

Regards
Stefan

[Yann E. MORIN]

Thomas, All,

Post by Thomas Petazzoni
Just like we have a post-build script mechanism that gets executed
after the build of all packages but before the creation of the
filesystem images, let's introduce a post-image script mechanism, that
gets executed once all filesystem images have been generated.

[--SNIP--]

Post by Thomas Petazzoni
diff --git a/Makefile b/Makefile
index 6f8ed0e..88b5a85 100644
--- a/Makefile
+++ b/Makefile

[--SNIP--]

Post by Thomas Petazzoni
@@ -548,6 +550,13 @@ target-generatelocales: host-localedef
done
endif
+ifneq ($(BR2_ROOTFS_POST_IMAGE_SCRIPT),)
+ $(s) $(BINARIES_DIR)$(sep))

No need to pass $(BINARIES_DIR) as it now is in the environment.

Would it make sense to run this under fakeroot?

Also, I wonder if we could instead call these scripts for each image we
generate, so it will already be run under fakeroot.

Not sure how to pass the image type to the script, though.
Maybe, something like:
post-image.sh <image-file> <image-type> <compression>

with image-type ∈ {tar,ext2,squashfs...}
and compression ∈ {none,gz,bz2,lzma,xz...}

And the script would typically contain:

#!/bin/sh
img_type="${1}"
img_file="${2}"
img_comp="${3}"
case "${img_type}" in
tar)
handle_tar "${img_file}" "#{img_comp}"
;;
squashfs)
handle_squash "${img_file}"
;;
*)
# Ignore other types
;;
esac

At least, I find it more interesting.

Regards,
Yann E. MORIN.

[Thomas Petazzoni]

Dear Yann E. MORIN,

Post by Yann E. MORIN
No need to pass $(BINARIES_DIR) as it now is in the environment.

I'd prefer to pass $(BINARIES_DIR) as argument, in order to keep a
symmetry with what we do for the post-build script.

Post by Yann E. MORIN
Would it make sense to run this under fakeroot?

Why?

Post by Yann E. MORIN
Also, I wonder if we could instead call these scripts for each image
we generate, so it will already be run under fakeroot.

No, I don't think it's a good idea. For example, in my use-case, it was
used to create a firmware image that bundles multiple images generated
by Buildroot. So getting called on a per-image basis doesn't make sense.

Post by Yann E. MORIN
Not sure how to pass the image type to the script, though.
post-image.sh <image-file> <image-type> <compression>
with image-type ∈ {tar,ext2,squashfs...}
and compression ∈ {none,gz,bz2,lzma,xz...}
#!/bin/sh
img_type="${1}"
img_file="${2}"
img_comp="${3}"
case "${img_type}" in
tar)
handle_tar "${img_file}" "#{img_comp}"
;;
squashfs)
handle_squash "${img_file}"
;;
*)
# Ignore other types
;;
esac
At least, I find it more interesting.

Unfortunately, not me. Calling a script once all images are generated
is *simple*, the script is free to do whatever it wants. Iterate over
all images, iterate over certain images only, etc. There is really no
need to over-engineer this thing.

I really don't see the point of putting more complexity into this.
Let's have something nicely symmetric between the post-build script
feature and the post-image script feature.

Best regards,

Thomas

[Yann E. MORIN]

Thomas, All,

Post by Thomas Petazzoni

Post by Yann E. MORIN
No need to pass $(BINARIES_DIR) as it now is in the environment.

I'd prefer to pass $(BINARIES_DIR) as argument, in order to keep a
symmetry with what we do for the post-build script.

Post by Yann E. MORIN
Would it make sense to run this under fakeroot?

Why?

For example, I need to create multiple partitions for my device, so I
need one file system image per partition:
- vfat on /boot
- squashfs on /
- ext2 on /home

So I would :
- configure Buildroot to build only a tarball
- configure Buildroot to run my post-image script
- extract the tarball
- generate each file system images

But the untar would loose the device nodes and the files UIDs and GIDs,
forcing me do run fakeroot inside the script, saving/loading the fakeroot
DB, for every commands in my script.

Having Buildroot do the fakeroot would ensure this consistency.

Post by Thomas Petazzoni

Post by Yann E. MORIN
Also, I wonder if we could instead call these scripts for each image
we generate, so it will already be run under fakeroot.

No, I don't think it's a good idea. For example, in my use-case, it was
used to create a firmware image that bundles multiple images generated
by Buildroot. So getting called on a per-image basis doesn't make sense.

OK, so it makes sense to run the scripts only once at the end. Agreed.

[--SNIP--]

Post by Thomas Petazzoni
I really don't see the point of putting more complexity into this.
Let's have something nicely symmetric between the post-build script
feature and the post-image script feature.

Right, agreed.

Regards,
Yann E. MORIN.

[Jeremy Rosen]

I think we have two different use cases here...


* we need a hook within fakeroot to make multiple images when each image is a different partition

* we need a hook post-image to bundle multiple images into a single binary files

that's a lot of hook, but i'm not sure how to not have all of them...

Regards

Jérémy Rosen

fight key loggers : write some perl using vim

[Yann E. MORIN]

Post by Thomas Petazzoni
Just like we have a post-build script mechanism that gets executed
after the build of all packages but before the creation of the
filesystem images, let's introduce a post-image script mechanism, that
gets executed once all filesystem images have been generated.
This can for example be used to call a tool building a firmware image
from different images generated by Buildroot, or automatically extract
the tarball root filesystem image into some location exported by NFS,
or any other custom action.

That is really usefull! Thank you! :-)

Post by Thomas Petazzoni
---
Makefile | 9 +++++++++
system/Config.in | 18 ++++++++++++++++++
2 files changed, 27 insertions(+)
diff --git a/Makefile b/Makefile
index 6f8ed0e..88b5a85 100644
--- a/Makefile
+++ b/Makefile
@@ -353,6 +353,8 @@ endif
include fs/common.mk
+TARGETS+=target-post-image
+
TARGETS_CLEAN:=$(patsubst %,%-clean,$(TARGETS))
TARGETS_SOURCE:=$(patsubst %,%-source,$(TARGETS) $(BASE_TARGETS))
TARGETS_DIRCLEAN:=$(patsubst %,%-dirclean,$(TARGETS))
@@ -548,6 +550,13 @@ target-generatelocales: host-localedef
done
endif
+ifneq ($(BR2_ROOTFS_POST_IMAGE_SCRIPT),)
+ $(s) $(BINARIES_DIR)$(sep))
+endif
+
./support/scripts/eclipse-register-toolchain `readlink -f $(O)` $(notdir $(TARGET_CROSS)) $(BR2_ARCH)
diff --git a/system/Config.in b/system/Config.in
index 69863c4..1ffe8a0 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -265,4 +265,22 @@ config BR2_ROOTFS_POST_BUILD_SCRIPT
only argument. Make sure the exit code of those scripts are 0,
otherwise make will stop after calling them.
+config BR2_ROOTFS_POST_IMAGE_SCRIPT
+ string "Custom script to run after creating filesystem images"
+ default ""
+ help
+ Specify a space-separated list of scripts to be run after
+ the build has finished and after Buildroot has packed the
+ files into selected filesystem images.
+
+ This can for example be used to call a tool building a
+ firmware image from different images generated by Buildroot,
+ or automatically extract the tarball root filesystem image
+ into some location exported by NFS, or any other custom
+ action.
+
+ These scripts are called with the images directory name as
+ first and only argument. The script is executed from the
+ main Buildroot source directory as the current directory.
+
endmenu
--
1.7.9.5
_______________________________________________
buildroot mailing list
http://lists.busybox.net/mailman/listinfo/buildroot

[Luca Ceresoli]

Post by Thomas Petazzoni
Just like we have a post-build script mechanism that gets executed
after the build of all packages but before the creation of the
filesystem images, let's introduce a post-image script mechanism, that
gets executed once all filesystem images have been generated.
This can for example be used to call a tool building a firmware image
from different images generated by Buildroot, or automatically extract
the tarball root filesystem image into some location exported by NFS,
or any other custom action.

Acked-by: Luca Ceresoli <luca-ep08DiM7hqZH3+***@public.gmane.org>

[Thomas Petazzoni]

This mechanism of root filesystem customization has been deprecated
since a long time, so let's remove it now.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/***@public.gmane.org>
---
package/Config.in | 1 -
package/customize/Config.in | 7 -------
package/customize/customize.mk | 32 --------------------------------
3 files changed, 40 deletions(-)
delete mode 100644 package/customize/Config.in
delete mode 100644 package/customize/customize.mk
delete mode 100644 package/customize/source/.empty

diff --git a/package/Config.in b/package/Config.in
index ba03b3c..5c78784 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -1,7 +1,6 @@
menu "Package Selection for the target"

source "package/busybox/Config.in"
-source "package/customize/Config.in"

# Audio and video applications
source "package/multimedia/Config.in"
diff --git a/package/customize/Config.in b/package/customize/Config.in
deleted file mode 100644
index 8f8aaa2..0000000
--- a/package/customize/Config.in
+++ /dev/null
@@ -1,7 +0,0 @@
-config BR2_PACKAGE_CUSTOMIZE
- bool "customize"
- depends on BR2_DEPRECATED
- help
- Add custom stuff to your buildroot.
-
- (edit package/customize/customize.mk)
diff --git a/package/customize/customize.mk b/package/customize/customize.mk
deleted file mode 100644
index d2b8518..0000000
--- a/package/customize/customize.mk
+++ /dev/null
@@ -1,32 +0,0 @@
-#############################################################
-#
-# Any custom stuff you feel like doing....
-#
-#############################################################
-CUST_DIR:=package/customize/source
-
-$(BUILD_DIR)/.customize:
- rm -f $(BUILD_DIR)/series
- (cd $(CUST_DIR); \
- /bin/ls -d * > $(BUILD_DIR)/series || \
- touch $(BUILD_DIR)/series )
- for f in `cat $(BUILD_DIR)/series`; do \
- cp -af $(CUST_DIR)/$$f $(TARGET_DIR); \
- done
- rm -f $(BUILD_DIR)/series
- touch $@
-
-customize: $(BUILD_DIR)/.customize
-
-customize-clean:
- rm -f $(BUILD_DIR)/.customize
-
-.PHONY: customize
-#############################################################
-#
-# Toplevel Makefile options
-#
-#############################################################
-ifeq ($(BR2_PACKAGE_CUSTOMIZE),y)
-TARGETS+=customize
-endif
diff --git a/package/customize/source/.empty b/package/customize/source/.empty
deleted file mode 100644
index e69de29..0000000

[Arnout Vandecappelle]

Post by Thomas Petazzoni
This mechanism of root filesystem customization has been deprecated
since a long time, so let's remove it now.

Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout-***@public.gmane.org>

It can also be removed from pkg-stats.

And maybe it should be added to Config.in.legacy?

Regards,
Arnout

[Yann E. MORIN]

Post by Thomas Petazzoni
This mechanism of root filesystem customization has been deprecated
since a long time, so let's remove it now.

As Arnout suggested, it would be nice to add this to the legacy checks.
I'm afraid people who used that will be highly disapointed when they
see thir builds breaks without warning.

Post by Thomas Petazzoni
---
package/Config.in | 1 -
package/customize/Config.in | 7 -------
package/customize/customize.mk | 32 --------------------------------
3 files changed, 40 deletions(-)
delete mode 100644 package/customize/Config.in
delete mode 100644 package/customize/customize.mk
delete mode 100644 package/customize/source/.empty
diff --git a/package/Config.in b/package/Config.in
index ba03b3c..5c78784 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -1,7 +1,6 @@
menu "Package Selection for the target"
source "package/busybox/Config.in"
-source "package/customize/Config.in"
# Audio and video applications
source "package/multimedia/Config.in"
diff --git a/package/customize/Config.in b/package/customize/Config.in
deleted file mode 100644
index 8f8aaa2..0000000
--- a/package/customize/Config.in
+++ /dev/null
@@ -1,7 +0,0 @@
-config BR2_PACKAGE_CUSTOMIZE
- bool "customize"
- depends on BR2_DEPRECATED
- help
- Add custom stuff to your buildroot.
-
- (edit package/customize/customize.mk)
diff --git a/package/customize/customize.mk b/package/customize/customize.mk
deleted file mode 100644
index d2b8518..0000000
--- a/package/customize/customize.mk
+++ /dev/null
@@ -1,32 +0,0 @@
-#############################################################
-#
-# Any custom stuff you feel like doing....
-#
-#############################################################
-CUST_DIR:=package/customize/source
-
- rm -f $(BUILD_DIR)/series
- (cd $(CUST_DIR); \
- /bin/ls -d * > $(BUILD_DIR)/series || \
- touch $(BUILD_DIR)/series )
- for f in `cat $(BUILD_DIR)/series`; do \
- cp -af $(CUST_DIR)/$$f $(TARGET_DIR); \
- done
- rm -f $(BUILD_DIR)/series
-
-customize: $(BUILD_DIR)/.customize
-
- rm -f $(BUILD_DIR)/.customize
-
-.PHONY: customize
-#############################################################
-#
-# Toplevel Makefile options
-#
-#############################################################
-ifeq ($(BR2_PACKAGE_CUSTOMIZE),y)
-TARGETS+=customize
-endif
diff --git a/package/customize/source/.empty b/package/customize/source/.empty
deleted file mode 100644
index e69de29..0000000
--
1.7.9.5
_______________________________________________
buildroot mailing list
http://lists.busybox.net/mailman/listinfo/buildroot

[Luca Ceresoli]

Post by Thomas Petazzoni
This mechanism of root filesystem customization has been deprecated
since a long time, so let's remove it now.

With Arnout's suggestions applied:
Acked-by: Luca Ceresoli <luca-ep08DiM7hqZH3+***@public.gmane.org>

[Thomas Petazzoni]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/***@public.gmane.org>
---
docs/manual/customize-rootfs.txt | 15 +++++++++++++++
1 file changed, 15 insertions(+)

diff --git a/docs/manual/customize-rootfs.txt b/docs/manual/customize-rootfs.txt
index 6399699..66e38dc 100644
--- a/docs/manual/customize-rootfs.txt
+++ b/docs/manual/customize-rootfs.txt
@@ -50,3 +50,18 @@ there are a few ways to customize the resulting target filesystem.
target root filesystem in +package/customize/source+, and then
enable this special package in the configuration system. _This
method is marked as deprecated_.
+
+Note also that if want to perform some specific actions *after* all
+filesystem images have been created (for example to automatically
+extract your root filesystem tarball in a location exported by your
+NFS server, or to create a special firmware image that bundles your
+root filesystem and kernel image, or any other custom action), you can
+specify a list of scripts in the +BR2_ROOTFS_POST_IMAGE_SCRIPT+
+configuration option. Each of those scripts will be called, with the
+path to the +images+ output directory as first and unique argument,
+and will be executed with the main Buildroot source directory as the
+current directory. Also, just like for the _post-build scripts_
+mentionned above, you also have access to the following environment
+variables from your _post-image scripts_: +BUILDROOT_CONFIG+,
++HOST_DIR+, +STAGING_DIR+, +TARGET_DIR+, +BINARIES_DIR+ and
++BASE_DIR+.

[Yann E. MORIN]

Thomas, All,

Post by Thomas Petazzoni
---
docs/manual/customize-rootfs.txt | 15 +++++++++++++++
1 file changed, 15 insertions(+)

Why did you split the doc-patch out of the feature-patch?

I would expect that documentation is committed in the same changeset as
the feature (or bug-fix) it relates to.

Regards,
Yann E. MORIN.

[Thomas Petazzoni]

Dear Yann E. MORIN,

Post by Yann E. MORIN
Thomas, All,

Post by Thomas Petazzoni
Signed-off-by: Thomas Petazzoni
docs/manual/customize-rootfs.txt | 15 +++++++++++++++
1 file changed, 15 insertions(+)

Why did you split the doc-patch out of the feature-patch?
I would expect that documentation is committed in the same changeset
as the feature (or bug-fix) it relates to.

Simply because not having the documentation doesn't prevent the feature
from working, but it makes the patch smaller, so easier to review, in
my opinion.

Thomas

[Yann E. MORIN]

Post by Thomas Petazzoni
---
docs/manual/customize-rootfs.txt | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/docs/manual/customize-rootfs.txt b/docs/manual/customize-rootfs.txt
index 6399699..66e38dc 100644
--- a/docs/manual/customize-rootfs.txt
+++ b/docs/manual/customize-rootfs.txt
@@ -50,3 +50,18 @@ there are a few ways to customize the resulting target filesystem.
target root filesystem in +package/customize/source+, and then
enable this special package in the configuration system. _This
method is marked as deprecated_.
+
+Note also that if want to perform some specific actions *after* all

...if you want...

Post by Thomas Petazzoni
+filesystem images have been created (for example to automatically
+extract your root filesystem tarball in a location exported by your
+NFS server, or to create a special firmware image that bundles your
+root filesystem and kernel image, or any other custom action), you can
+specify a list of scripts in the +BR2_ROOTFS_POST_IMAGE_SCRIPT+

... a space-separated list...

Post by Thomas Petazzoni
+configuration option. Each of those scripts will be called, with the
+path to the +images+ output directory as first and unique argument,
+and will be executed with the main Buildroot source directory as the
+current directory. Also, just like for the _post-build scripts_
+mentionned above, you also have access to the following environment
+variables from your _post-image scripts_: +BUILDROOT_CONFIG+,
++HOST_DIR+, +STAGING_DIR+, +TARGET_DIR+, +BINARIES_DIR+ and
++BASE_DIR+.

With those changes:
Acked-by: "Yann E. MORIN" <yann.morin.1998-***@public.gmane.org>

[Luca Ceresoli]

Post by Thomas Petazzoni
---
docs/manual/customize-rootfs.txt | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/docs/manual/customize-rootfs.txt b/docs/manual/customize-rootfs.txt
index 6399699..66e38dc 100644
--- a/docs/manual/customize-rootfs.txt
+++ b/docs/manual/customize-rootfs.txt
@@ -50,3 +50,18 @@ there are a few ways to customize the resulting target filesystem.
target root filesystem in +package/customize/source+, and then
enable this special package in the configuration system. _This
method is marked as deprecated_.
+
+Note also that if want to perform some specific actions *after* all
+filesystem images have been created (for example to automatically
+extract your root filesystem tarball in a location exported by your
+NFS server, or to create a special firmware image that bundles your
+root filesystem and kernel image, or any other custom action), you can
+specify a list of scripts in the +BR2_ROOTFS_POST_IMAGE_SCRIPT+
+configuration option. Each of those scripts will be called, with the
+path to the +images+ output directory as first and unique argument,
+and will be executed with the main Buildroot source directory as the
+current directory. Also, just like for the _post-build scripts_
+mentionned above, you also have access to the following environment

s/mentionned/mentioned/

With that fix:
Acked-by: Luca Ceresoli <luca-ep08DiM7hqZH3+***@public.gmane.org>

[Thomas Petazzoni]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/***@public.gmane.org>
---
docs/manual/customize-rootfs.txt | 6 ------
1 file changed, 6 deletions(-)

diff --git a/docs/manual/customize-rootfs.txt b/docs/manual/customize-rootfs.txt
index 66e38dc..ce62412 100644
--- a/docs/manual/customize-rootfs.txt
+++ b/docs/manual/customize-rootfs.txt
@@ -45,12 +45,6 @@ there are a few ways to customize the resulting target filesystem.
stored
- +BASE_DIR+: the base output directory

-* A special package, 'customize', stored in +package/customize+ can be
- used. You can put all the files that you want to see in the final
- target root filesystem in +package/customize/source+, and then
- enable this special package in the configuration system. _This
- method is marked as deprecated_.
-
Note also that if want to perform some specific actions *after* all
filesystem images have been created (for example to automatically
extract your root filesystem tarball in a location exported by your

[Yann E. MORIN]

Thomas, All,

Post by Thomas Petazzoni
---
docs/manual/customize-rootfs.txt | 6 ------
1 file changed, 6 deletions(-)

Ditto. This should be folded with the previous cset.

Regards,
Yann E. MORIN.

[Yann E. MORIN]

Post by Thomas Petazzoni
---
docs/manual/customize-rootfs.txt | 6 ------
1 file changed, 6 deletions(-)
diff --git a/docs/manual/customize-rootfs.txt b/docs/manual/customize-rootfs.txt
index 66e38dc..ce62412 100644
--- a/docs/manual/customize-rootfs.txt
+++ b/docs/manual/customize-rootfs.txt
@@ -45,12 +45,6 @@ there are a few ways to customize the resulting target filesystem.
stored
- +BASE_DIR+: the base output directory
-* A special package, 'customize', stored in +package/customize+ can be
- used. You can put all the files that you want to see in the final
- target root filesystem in +package/customize/source+, and then
- enable this special package in the configuration system. _This
- method is marked as deprecated_.
-
Note also that if want to perform some specific actions *after* all
filesystem images have been created (for example to automatically
extract your root filesystem tarball in a location exported by your
--
1.7.9.5
_______________________________________________
buildroot mailing list
http://lists.busybox.net/mailman/listinfo/buildroot

[Luca Ceresoli]

Acked-by: Luca Ceresoli <luca-ep08DiM7hqZH3+***@public.gmane.org>

[Thomas Petazzoni]

The order of the solutions to customize the root filesystem is
changed: we now mention the post-build script mechanism *before* the
custom root filesystem skeleton mechanism, because the former is
preferred over the latter.

In addition to this, we give a few more details about direct
customization of the root filesystem in output/target, and about the
custom target skeleton solution.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/***@public.gmane.org>
---
docs/manual/customize-rootfs.txt | 29 ++++++++++++++++++-----------
1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/docs/manual/customize-rootfs.txt b/docs/manual/customize-rootfs.txt
index ce62412..9de98f7 100644
--- a/docs/manual/customize-rootfs.txt
+++ b/docs/manual/customize-rootfs.txt
@@ -12,17 +12,11 @@ there are a few ways to customize the resulting target filesystem.
simply make your changes here and run make afterwards - this will
rebuild the target filesystem image. This method allows you to do
anything to the target filesystem, but if you decide to completely
- rebuild your toolchain and tools, these changes will be lost.
- _Changes do not survive the +make clean+ command_.
-
-* Create your own 'target skeleton'. You can start with the default
- skeleton available under +system/skeleton+ and then customize it to
- suit your needs. The +BR2_ROOTFS_SKELETON_CUSTOM+ and
- +BR2_ROOTFS_SKELETON_CUSTOM_PATH+ will allow you to specify the
- location of your custom skeleton. These options can be found in the
- +System configuration+ menu. At build time, the contents of the
- skeleton are copied to output/target before any package
- installation.
+ rebuild your toolchain and tools, these changes will be lost. This
+ solution is therefore only useful for quick tests only: _changes do
+ not survive the +make clean+ command_. Once you have validated your
+ changes, you should make sure that they will persist after a +make
+ clean+ by using one of the following methods.

* In the Buildroot configuration, you can specify the path to a
*post-build script*, that gets called 'after' Buildroot builds all the
@@ -45,6 +39,19 @@ there are a few ways to customize the resulting target filesystem.
stored
- +BASE_DIR+: the base output directory

+* Create your own 'target skeleton'. You can start with the default
+ skeleton available under +system/skeleton+ and then customize it to
+ suit your needs. The +BR2_ROOTFS_SKELETON_CUSTOM+ and
+ +BR2_ROOTFS_SKELETON_CUSTOM_PATH+ will allow you to specify the
+ location of your custom skeleton. These options can be found in the
+ +System configuration+ menu. At build time, the contents of the
+ skeleton are copied to output/target before any package
+ installation. Note that this method is *not recommended*, as it
+ duplicates the entire skeleton, which prevents from taking advantage
+ of the fixes or improvements brought to the default Buildroot
+ skeleton. The recommended method is to use the _post-build script_
+ mechanism described in the previous item.
+
Note also that if want to perform some specific actions *after* all
filesystem images have been created (for example to automatically
extract your root filesystem tarball in a location exported by your

[Yann E. MORIN]

Post by Thomas Petazzoni
The order of the solutions to customize the root filesystem is
changed: we now mention the post-build script mechanism *before* the
custom root filesystem skeleton mechanism, because the former is
preferred over the latter.
In addition to this, we give a few more details about direct
customization of the root filesystem in output/target, and about the
custom target skeleton solution.
---
docs/manual/customize-rootfs.txt | 29 ++++++++++++++++++-----------
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/docs/manual/customize-rootfs.txt b/docs/manual/customize-rootfs.txt
index ce62412..9de98f7 100644
--- a/docs/manual/customize-rootfs.txt
+++ b/docs/manual/customize-rootfs.txt
@@ -12,17 +12,11 @@ there are a few ways to customize the resulting target filesystem.
simply make your changes here and run make afterwards - this will
rebuild the target filesystem image. This method allows you to do
anything to the target filesystem, but if you decide to completely
- rebuild your toolchain and tools, these changes will be lost.
- _Changes do not survive the +make clean+ command_.
-
-* Create your own 'target skeleton'. You can start with the default
- skeleton available under +system/skeleton+ and then customize it to
- suit your needs. The +BR2_ROOTFS_SKELETON_CUSTOM+ and
- +BR2_ROOTFS_SKELETON_CUSTOM_PATH+ will allow you to specify the
- location of your custom skeleton. These options can be found in the
- +System configuration+ menu. At build time, the contents of the
- skeleton are copied to output/target before any package
- installation.
+ rebuild your toolchain and tools, these changes will be lost. This
+ solution is therefore only useful for quick tests only: _changes do
+ not survive the +make clean+ command_. Once you have validated your
+ changes, you should make sure that they will persist after a +make
+ clean+ by using one of the following methods.
* In the Buildroot configuration, you can specify the path to a
*post-build script*, that gets called 'after' Buildroot builds all the
@@ -45,6 +39,19 @@ there are a few ways to customize the resulting target filesystem.
stored
- +BASE_DIR+: the base output directory
+* Create your own 'target skeleton'. You can start with the default
+ skeleton available under +system/skeleton+ and then customize it to
+ suit your needs. The +BR2_ROOTFS_SKELETON_CUSTOM+ and
+ +BR2_ROOTFS_SKELETON_CUSTOM_PATH+ will allow you to specify the
+ location of your custom skeleton. These options can be found in the
+ +System configuration+ menu. At build time, the contents of the
+ skeleton are copied to output/target before any package
+ installation. Note that this method is *not recommended*, as it
+ duplicates the entire skeleton, which prevents from taking advantage
+ of the fixes or improvements brought to the default Buildroot
+ skeleton. The recommended method is to use the _post-build script_
+ mechanism described in the previous item.
+
Note also that if want to perform some specific actions *after* all
filesystem images have been created (for example to automatically
extract your root filesystem tarball in a location exported by your
--
1.7.9.5
_______________________________________________
buildroot mailing list
http://lists.busybox.net/mailman/listinfo/buildroot

[Luca Ceresoli]

Post by Thomas Petazzoni
The order of the solutions to customize the root filesystem is
changed: we now mention the post-build script mechanism *before* the
custom root filesystem skeleton mechanism, because the former is
preferred over the latter.
In addition to this, we give a few more details about direct
customization of the root filesystem in output/target, and about the
custom target skeleton solution.

Acked-by: Luca Ceresoli <luca-ep08DiM7hqZH3+***@public.gmane.org>