[PATCH 1/4] setup.exe
Sat Feb 16 20:11:00 GMT 2013
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
> 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
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.
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Q+, Q and microQ:
More information about the Cygwin-apps