On Tue, Apr 13, 2010 at 9:32 AM, Neil Williams <codeh...@debian.org> wrote:
> > 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. > > I was suggesting that instead of having a single monolithic script per variant, to have an aggregated set of script fragments each specific to a package that get gathered and run en masse. You are correct that the overall combined contents of the scripts should be tightly tied to processing a given variant, but the flexibility I refer to is to have a fragment stored such that it can be reused across variants (possibly by simply copying it to a different variants script directory), to comprise the full scripted set of actions working on the root filesystem. 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. > Completely agreed, no running of the maintainer's scripts, since this is not done on device and the facilities to run them don't exist off box. > > 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. > Exactly. > > 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. > Agreed. > > 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. > > I meant a script running off the device to manipulate and update a rootfs. > > > 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? > I meant a fragment script (off box) that was dealing with the steps necessary to integrate busybox into the root filesystem. Since it is conceivable that busybox might be a package used in every system, I was suggesting that other generalized stuff (the boilerplate that might exist in a monolithic script) needed to handle system setup could be conveniently piggybacked into this packages script fragment. Perhaps that is gross, and having a generalized variant master script would be much more elegant. Such a master script could invoke the execution of the individual fragment scripts that are specific to each package. > 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. > > They change generally mostly as a new release becomes the new stable. -Jim Heck
