myDSL Extensions (deprecated) :: post install

minimally tested
FINAL EDIT: This first test was a failure, since i had some misconceptions of the DSL init process. Don't listen to anything I say in this first post.

The topic of a post-install script in myDSL extensions comes up once in a while....we were talking about it last night on irc, and I thought i'd give it a go. This first idea does not require a remaster, but instead uses a myDSL extension to add the post-install capability. It is simply an extension containing an edited version of /etc/init.d/mydsl-install, and named something like "0-POSTINSTALL.tar.gz" so it will be the first extension loaded in an auto-load situation (and will not bother running mkwriteable if you don't have a need for it).

The mockup post-install code, added to /etc/init.d/mydsl-install AFTER the "case $APP" and BEFORE "umount":

Code Sample

mydslPOSTINST="/tmp/mydsl.postInstall/postinst.sh"
if [ -x "$mydslPOSTINST" ]; then
sh $mydslPOSTINST && chmod -x $mydslPOSTINST
fi

I had originally hoped to use the APP variable in the script, but it wouldn't have worked if the package was ever renamed. The "chmod" isn't necessary, but as an afterthought it might be useful for something.

It requires adding a script named /tmp/mydsl.postInstall/postinst.sh to any package using post install behavior. This script needs to be executable.
It DOES NOT work with uci extensions. I don't think i want to bother incorporating post-install into mounted apps.

EDIT: After some minor tests it seems to work fine, both at boottime and with user-initiated install.

Test archive here:
link to crappy script removed. Better version available farther along in this thread

Archive contains 3 myDSL packages: The post-install (edited mydsl-install script), one *.tar.gz test and one *.dsl test.
Don't test on anything but a non-persistent liveCD or frugal, just to be safe.

EDIT2: I just remembered that mydsl-install is run as root, which would mean that the post-install script is currently also run as root. Just something to keep in mind.

EDIT3: My bad...it doesn't work at boot time, since dsl-config doesn't run mydsl-load...it extracts the contents of the archives with tar directly.

Of course this approach won't work for apps loaded at boot because as we discussed last night further steps need to be taken.

mydsl-install is not called from dsl-config... it instead installs all the packages itself... so you actually need to inject a special script into runlevel 2 or 5 (you could put it in S, but I don't think the list of things to run is dynamically reloaded, when dsl-config is running it's probably already scanned rcS for things to run and too late to add anything).

And since multiple packages can be installed at boot (before we have the ability to run post-install scripts) they really do need to be named according to the package... package names should be ALMOST static so I don't see this as a big deal... You could also name them sequentially, which might make sense for ordering of dependencies... 0.install, 1.install, 2.install, etc...

And since it isn't happening immediately I'm still not a big fan of using /tmp... but maybe that's the only writable place at this point, not sure... so you'd have...

/tmp/mydsl.postInstall/gtk2
/tmp/mydsl.postInstall/gimp
/tmp/mydsl.postInstall/xfce

The names really don't even matter... You could even dump:

/temp/mydsl.postInstall/gimp-step1
/temp/mydsl.postInstall/gimp-step2

Of course I have no idea why you wouldn't just have one script, but not locking the names approach allows this additional flexibility.

At startup the final script loops over any of these files running them... there should also really be some mechanism to catch failures and leave the scripts for manual intervention, but that might be stage two...

If I have time this week I'll see about implimenting the full mechanism and updating the 4 test packages I maintain to use the new system...

Thoughts?

Ok, take my # idea back... it didn't make much sense... it'd require a lot more logic to take a certain file and order it for later execution...

My next question is... in light of the fact that I think failures should be handled gracefully is this the script or controllers job?

There are two approachs I see... the "master" script runs instlals, checks for success, removes install scripts or prints error and leaves it (for manual intervention)...

Or the master script is more dumb and just runs thigns in order and the install scripts have more logic... I like this approach... an install would either print an error and then exit... or print success (or do nothing) and rm $0 (remove itself)... seems a very clean approach to me...

Not much effort on the master and really not much additional effort on the install script maintainers... we should all be checking for errors in some rudimentary form at least... right? :-)

My proposal (I just wrote this off the top of my head):

Added to /etc/init.d/mydsl-install (after case/esac and before umount)

Code Sample

. /etc/init.d/mydsl-postinstall

/etc/init.d/mydsl-postinstall

Code Sample

for file in `ls /tmp/mydsl.postInstall/*`; do
$file
done

/etc/rc2.d/S25post_install and
/etc/rc5.d/S25post_install

Code Sample

-> (link to) /etc/init.d/mydsl-postinstall

Of course it might be a little more complex than that.. but that's the jist of it... the only issue with this system is packages overlapping names during boot up... ie you couldn't install TWO gimps... packages could not overlapp their /tmp/mydsl.postInstall files... if there is gimp1 and gimp2 (as in having both versions installed) those would be the respective names of their install files...

This addresses all of my previous thoughts i think and it still trivially simple...

Though truth be told I don't like camelCase directories...

maybe /tmp/mydsl_postinstall/ instead or add another underscore? of course i don't really care too much :-)

Next Page...
original here.