On Tue, Apr 13, 2010 at 9:32 AM, Neil Williams
<codehelp@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.