[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Crush and maintainer scripts - Emdebian BAKED

No. Not at all. In Baked, the entire system configuration is up for
grabs - if you don't implement it, it won't exist.

Multistrap won't have any preinst or postinst scripts to run - the
"baking" process happens in two stages:

1. Packages are "baked" by emgrip and put into a (local) repository

2. Multistrap takes packages from that repository and creates the root
filesystem - various hooks are used to implement all the configuration
you need and nothing in the package installation process would change
that. Necessarily, if a package modifies some configuration *at
runtime* then that happens as normal.

Or would the developer need to craft some of the preinst/postinst
actions on their own (such as creating runlevel links, etc.)?  I ask,
Not as preinst and postinst, you'd simply write a script that does the
entire job for all packages in one step.

Does this mean that there won't be an opportunity to keep these scripts granular per package? Even though a given system configuration does not change, it is conceivable to think that a given repository of packages might support more than one embedded system with different constituent packages. It would therefore benefit by having each package still have a given script run that does the needed steps to integrate it into a given system. An overall script may be needed for some things (perhaps the busybox script could stand in for general system configuration if it is always present), but the extent to which individual packages remain independent flexibility is gained.
Changes in Debian packages will not affect your configuration with
The point I was trying to make is that since the script written by the developer is static, that if the upstream package does something like changing the runlevel ordering of something in the initscripts for the system relating to a given package, that the change would need to be manually picked up by the developer and a corresponding change made to their script, or things would be broken. These changes don't happen often, but often enough to make this error prone. I was wishing for some way to at least know when such a change has been made. I understand that the only practical thing to do is to strip out all the scripts and let the developer recreate just what they need, but in my experience, this usually boils down to a few repeatable steps such as installing links in the initscripts, creating a few softlinks, etc.

Also a general comment. I have to commend you (Neil) and the rest of the Emdebian folks, this project is really turning into something very neat! Great work.

-Jim Heck

Reply to: