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
pgp4PwzeZt5M1.pgp
Description: PGP signature
