This is the mail archive of the cygwin-apps mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Nov 21 22:00, Achim Gratz wrote: > Corinna Vinschen writes: > > Assuming we only have a single rebaseall script along the lines of > > autorebase.bat. > > > > A simple mechanism which works with both of your proposals, without > > much intelligence required, without clobbering, and with easy cygport > > support, would be this: > > > > autorebase.bat gets renamed to 2r-autorebase.bat (Achim) or > > 02-autorebase.bat (Yaakov), > > > > To handle the dependency issue, every package coming with DLLs will not > > create the same 01-rebaseall.{sh,bat} script as Yaakov proposed, but > > rather a script called, for instance, > > > > 1r-needrebase-${packagename}.sh (Achim) > > or 01-needrebase-${packagename}.sh (Yaakov) > > For rebase in particular there's no two-step sequencing needed, > actually. Just dropping files with a list of to-be rebased objects is > enough, plus a perpetual script that picks them up before the rest of > the postinstall and feeds them to rebase. But we already have that in > the form of the package.lst.gz files and filtering out the file names to > be rebased from that actually doesn't take much more time then using a > packaged list. I don't understand this one. The lst.gz files don't tell you which of them are newly installed/updated. But, anyway, I trust that you had that thought out. > Autodep generation would be even easier since setup > knows which file it dropped or deleted and could trigger a rebase based > on that information all by itself. That rule could even be hardcoded, > it's not going to change often. Ideally I'd prefer if setup would only do the generic part of this, collecting and propagating information of new or updated files, running scripts using a pattern-based algorithm, whatever. It shouldn't run specific scripts based on hardcoded rules. > > Same thing for update-info-dir. Am I missing something? > > You're not. That's how triggers are supposed to work for this sort of > thing, especially and can even be auto-generated by setup (package > installs a file in an infodir: run update-info, both on install and > remove) and would not require dropping of trigger scripts. Simple triggers based on file suffixes might be nice: 1t-dll,so,oct-rebase.bat 2t-info-update-info-dir.bat I'm surr you can guess how and when I mean them to run ;) > The objective that shapes my proposal was to not require much support > from either setup or cygport or even manual intervention in the > beginning. Once it is fully implemented, things could be realized very > differently (and hopefully more efficiently) that they are now. They > don't have to, though. Sounds good to me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
pgpuFBpqzn5EQ.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |