Christopher Faylor writes: > Are you trying to say that the package containing an autorun script > must run its postinstall.sh before anything else?
No, only that it must be installed so that the script to autorun is accessible when it triggers. This could of course be handled by stipulating that all packages defining autoruns must be in the "Base" category. If that is not desired, then obviously there's the possibility that the package isn't installed (or outdated) when the autorun rule it defines triggers and setup.exe should IMHO install or update it in this case. > I don't really see the need for a postinstall.sh for any of the > current use cases but, ok, yes, that would be a wrinkle for this > scenario. However, I'm comfortable with imposing a "autorun packages > should not require a postinstall.sh script to operate" rule.[ Currently a side effect of how things are implemented is indeed that the autorun script is actually a postinstall script and the package name determines when it is run. But no, I wouldn't want to keep it that way. The package providing the autorun script should not need or have a postinstall script, precisely because we would otherwise need to carefully orchestrate the order in which to run the postinstall scripts. > We're talking about something that *I* suggested. I'm laying out the > ground rules. It actually *does* matter that something should be run > when a .info file is deleted but it's not a crucial thing to implement > right now. OK, I didn't understand where that was coming from, since the first part of your comment seemed to be directed at autodep and it currently doesn't care about deletions. Yes, when things get removed that might be another reason to autorun something (to free up address space in the rebase DB for instance), but it wouldn't necessarily need to run the same script. So we would either need to have a separate keyword or the autorun script should be invoked with an argument so that it can distinguish between these two cases. > It doesn't have to be a library. Cygwin's regexec.c would probably > suffice. I'll have a look. > I actually posted the current autodep line for the _autorebase package. > It did not (and should not) rely on file prefixes. No, of course not; it matches one of three file extensions, something that is trivial to implement without a regex parser. I still think that it would be safer if we didn't try to parse arbitrary regex, and certainly more performant if there are many such rules. But if there's a genuine need for full regex parsing… Regarding another comment you've made earlier: for triggering the autorun script we'd only need to check until the first match is found and could then skip checking for that particular trigger later on. If on the other hand you would want to be able to get a list of file names that triggered the rule, we'd need to always check them all and also collect them into a list so that for instance they could become an argument to the script. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds