Execute some of the first boot scripts as part of the build process

[bonefish]

Particularly for releases it would be nice to allow running some of the first boot (post_install) scripts as part of the build process. I'm especially thinking of mime_update.sh which can take quite a while.

This could work as follows:

• A configure script option or environmental/build system variable would trigger the feature.
• The built image would contain a special Bootscript that executes the scripts in question, replaces itself by the real Bootscript, and shuts down the system.
• The build system -- or rather B-O-M -- would simply boot such an image via qemu to finalize it.

Obviously this works only for writable images, i.e. raw, VMware, and anyboot. For the ISO CDs we'd have to continue to use the current method; though I'm in favor of phasing those out anyway.

[andreasf]

Why can't the equivalent of mime_update.sh be done from the build process? Haiku should know where it just created its B_DESKTOP_DIRECTORY and B_SYSTEM_DIRECTORY, thus no need for finddir. So, is it the query call?

[bonefish]

Replying to andreasf:

Why can't the equivalent of mime_update.sh be done from the build process?

It could be done, it's just a way more complicated solution. What I proposed can be implemented in a few minutes plus testing.

Haiku should know where it just created its B_DESKTOP_DIRECTORY and B_SYSTEM_DIRECTORY, thus no need for finddir. So, is it the query call?

The main issue is that it all has to happen in the image. ATM the only way to access the image is via the shell-like commands the bfs_shell provides. Something like query could be added relatively easily, but mimeset is non-trivial, since under Haiku its main work is done by the registrar.

Anyway, I guess the cleanest solution -- one that would work for all installation targets -- would be to install everything in a temporary directory first, perform all post installation tasks, and then just copy it to the blank image, create an ISO image from it, or copy it to the installation directory. An obviously nice advantage is that it minimizes the installation target specific interface to a single "copy to target" function.

[diver]

I think this was fixed with package management, or there's something left?

[pulkomandy]

There are still two scripts which we may be able to replace this way:

add_catalog_entry_attributes.sh
default_deskbar_items.sh

However they are much simpler than the mimeset one, so: 1) They run faster 2) They are easier to move to the build system, I think

Also add_catalog_entry_attributes.sh mentions that it tries to write to read-only directories and doesn't work, anyway.