Re: Crush and maintainer scripts - Emdebian BAKED
Longtime lurker here.
Overall I think this is an excellent idea.
I can validate that there is use for this approach, since it parallels
in many ways the roll it yourself method for maintaining a small
embedded "baked" distribution currently used by a commercial product I
work on. Once the system is installed there is no need (short of a
forklift upgrade) to manipulate packages. I think many systems will
share this trait. If I understand correctly, Emdebian just got a whole
lot more interesting to me, since it would allow me a path to apply it
to a project that already uses an embedded baked root filesystem,
without adding much overhead.
On 4/13/2010 4:12 AM, Neil Williams wrote:
The expectation would then be that multistrap would work with such
local repositories to impose the relevant configuration using device
table files, pre-configured files to go into /etc/ and various other
Forgive my ignorance (I lurk, but I admit I'm not up to speed with how
things currently work..), but I have a question. Would the scripts
(preinst, postinst...) get run once by some part of the emdebian
toolchain process (multistrap?) that builds the baked root filesystem?
Or would the developer need to craft some of the preinst/postinst
actions on their own (such as creating runlevel links, etc.)? I ask,
since in our approach, the preinst scripts are converted into python
scripts that distill down to the essential steps needed to install the
package and are run on the expanded root filesystem. This is one of the
big drawbacks to the roll it yourself approach I currently have to
maintain, since I have to adjust the scripts every time an upstream
package changes if they do something different or new.
One extra step for Baked would be that your final multistrap hook could
forcibly remove dpkg and apt as well as the /var/lib/dpkg/ contents.
Multistrap won't be able to do this for you (neither will debootstrap)
because apt cannot be persuaded not to install itself. :-) When I say
remove, it would be 'rm -rf /paths/to/dpkg/files' not 'dpkg -P' -
leaving the system theoretically setup with dpkg but without dpkg or
dpkg status files. This would gain several Mb of free space which could
be advantageous for such a system.
Baked could be set just by providing the relevant file
in /etc/dpkg/origins and setting the DEB_VENDOR environment variable
when processing the packages with emgrip.
If this is suitable for anyone please let me know if there are other
components of packages that should also be removed. Presumably such a
system would not require md5sums files, symbols files or shlibs files.
Many packages carry default files for /etc/ - I'd say it's worth
keeping those and modifying them later if appropriate rather than
removing them all and having to pre-bake everything.
Emdebian Baked would NOT be expected to support a large number of
packages per system - typical expectations are one or maybe two dozen
packages at absolute most, including the kernel.
As with other Emdebian variants, although the emphasis is on reducing
absolute package size, I still think that devices where space is not an
issue would still benefit from this approach by selecting those
packages from Debian that have sufficiently low resource expectations
and mixing those into the package set.