[RFC] incremental rebase

[Corinna Vinschen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20141121/4fa0d521/attachment.sig>