On Tue, 13 Apr 2010 08:24:01 -0400 Jim Heck <jsurf@heckheck.com> wrote: > > 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? Better to have scripts that are granular per device variant. With the 'mv' instead of 'rm' feature, you would have a copy of the original scripts (which include the package name in the filename) but then you've still got the original problem - you cannot run the maintainer scripts except on the device. The off-device script is written specifically to cope with altering stuff in the rootfs instead of trying to mangle scripts that are expecting to run on-device. The package maintainer scripts aren't useful off-device except for comparison. To let these run on the device, you would need to put dpkg back onto the machine. > 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. One repository for multiple variants - yes. The scripts would be run by multistrap and therefore creating one variant rootfs means selecting one multistrap config vs another. One rootfs per variant. > 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. On the device? That would need to be Crush or Grip. Off device? Copy over an updated rootfs. That's why Baked can work - it doesn't allow updates other than re-baking. However, unlike other methods, the baking is separated from the package building - you simply update the packages in the repository and run builds from those packages until you next want to update. > 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. busybox script? which ones that? > The point I was trying to make is that since the script written by the > developer is static, The configuration per device is static, the script can be modified because that lives off-device. The script writes stuff to the device rootfs - the rootfs doesn't need to do anything. (Hence Baked is pre-configured.) > 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. It would only be broken for the next run of root filesystem builds. In most cases, such builds take packages from Debian stable so the packages don't change that much. > 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. You would have access to copies of the maintainer scripts from each variant build. One way to do this would be to run the build for a native architecture and then do a comparison of the final configuration. > 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. Quite - that's why the maintainer scripts are too general and doing lots of unnecessary checks. Better to do those checks yourself. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgprDj_RLYntH.pgp
Description: PGP signature