Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Date: Tue, 26 Feb 2002 16:26:53 -0500
From: Jason Tishler <jason AT tishler DOT net>
Subject: Re: setup.exe rebase patch
In-reply-to: <018901c1be4f$6752fbb0$0200a8c0@lifelesswks>
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
Cc: Cygwin-Apps <cygwin-apps AT sources DOT redhat DOT com>
Mail-followup-to: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>,
 Cygwin-Apps <cygwin-apps AT sources DOT redhat DOT com>
Message-id: <20020226212652.GC2288@hp.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
User-Agent: Mutt/1.3.24i
References: <20020207134119 DOT GB1804 AT dothill DOT com>
 <027701c1bd28$c4666170$0200a8c0 AT lifelesswks> <20020225153441 DOT GA2544 AT hp DOT com>
 <018901c1be4f$6752fbb0$0200a8c0 AT lifelesswks>

Rob,

On Tue, Feb 26, 2002 at 09:54:37AM +1100, Robert Collins wrote:
> ----- Original Message -----
> From: "Jason Tishler" <jason AT tishler DOT net>
> > I guess that I was trying to ask a more philosophical question of how
> > coupled rebase was going to be with setup.exe.  It sounds like you are
> > comfortable with a tight coupling.  Is this correct?
> 
> Yes. I think that setup.exe based rebasing should be optional, but
> default to on. A flag in rebase.conf to control this would be good,
> along with a dialogue box and a tick :]. Not needed for the initial
> merge though.

OK, sounds good.  I'm not a GUI guy -- I hope that Gary will come to my
rescue. :,)

> > I haven't tried LoadLibrary(), etc. but I presume that one of the
> > APIs can.  However, isn't this too little, too late?  What can we do
> > when the corruption occurs?  Rollback to the copy in the archive?
> > But, then this image will *not* be rebased. :,(
> 
> I was thinking of the following process (for all dlls we attempt to
> rebase):
> 0) Check that it hasn't been rebased already.

What is the purpose of the above?  I already rebase DLLs into their
previous space during reinstalls, if they still fit.

> 1) Copy
> 2) Rebase
> 3) Check for corruption - mark as occupying it's own prior space if
> corrupt and then stop, otherwise mark it's new space in the used list.

What happens when the prior space is already taken?

> We can yes, it's certainly not urgent. My concept rough concept on the
> process was that rebasing would be moved out of the install routines
> (because uninstalls free up used list space) and be made to occur after
> all the files have been installed, we'd have a complete list of .dll's
> that need may rebasing, and whose dependents should be checked at the
> same time.

Is the "complete list" approach above required for the first iteration?

> (Or do you rebase cygwin1.dll as well :]]).

Yes, I can rebase cygwin1.dll too.  This is why I converted the
stand-alone rebase to a Mingw app.

> > > 1) log.cc - don't clean up there. If you need to cleanup, have a
> > > static object whose destructor should get called.
> >
> > This is already done too (see rebaser.cc:338).  Note that my
> > stand-alone rebase.exe is already using this successfully.
> 
> Gotcha, ok the log.cc call should go then - or does this introduce sife
> effects?

Currently, the config file won't be saved.  This won't be a problem once
the config file is saved as soon as the installation phase is finished.

> > > 2) I really don't like the rebaser::set_cygwin_root_dir construct:
> > > why not use get_root_dir () when you need the cygwin root? (Any
> > > why do you need it? Surely you only need cygpath (filename) ?
> >
> > This is for the stand-alone case which I wasn't sure was going to be
> > able to easily share code with setup.exe.  This concern appears to
> > be mitigated.  I can certainly have rebaser always retrieve the Cygwin
> > root from the registry if this is deemed the better approach.
> 
> Ah. Well within setup io_stream is the answer as they

Huh?  You didn't finish the above sentence.

> > I tried to find the appropriate abstractions in the problem domain.
> > I tried to encapsulate implementations behind reasonable interfaces to
> > minimize the impact of implementations changes.  Etc, etc.  However,
> > I'm open to design changes too, if deemed necessary.
> 
> What feels procedural is separate classes for serialisation. I _feel_
> (And can there for be told to get my nose out of it) that a better
> encapsulation would be for the used list and free list to have
> [de]serialisation capability, and the config_file class to shrink to
> simply finding the config file, identifying the beginning of (say) a
> used list section, and then passing the buck. Would you care to comment
> on this as opposed to your current model?

Ah, I see your point.  I guess that it depends on how you want to slice
and dice.  I have used the load/save paradigm many times before and in
general prefer it.  However, in this case I don't quite think of the
config file data as object state.  What happens if there are syntax
errors, etc.?  I think that a config file object should deal with these
kinds of issues (although is could delegate some of the responsibility to
the list objects).  Additionally, with my current approach I can change
the config file format without affecting the list classes.

Nevertheless, if you feel strongly, then I will change my perspective.

> > > 9) Should we rename my 'list.h' to 'vector.h'
> >
> > vector does seem to better capture the semantics.  But, what is the
> > relevance to my list code?  Are you suggesting that I use your stuff.
> > I tried but I needed STL map-like functionality.
> 
> I'm suggesting I get my stuff out of your way :}. Your code seems
> traditional list based, which mine isn't (anymore), so your code could
> generalise to be a list/map template.

OK, sounds good.

> > > 10) Please capitalise the first letter of words in class names.
> > > Setup has been quite haphazard, I'm trying to be more consistent :}.
> > > Also, I prefer things like FreeList to free_list - I find them easier.
> >
> > The above made me smile!  I completely agree with you.  However, I was
> > just trying to follow the GNU coding style.  Specifically, the
> > following item is relevant here:
> >
> >     http://www.gnu.org/prep/standards_26.html#SEC26
> 
> Erk. Well I use VI :]. cinstall isn't a Gnu Project, and I've always
> taken the standards as guidelines rather than godlines.

Since Cygwin follows the GNU coding style, I just assumed that setup.exe
did too.

Thanks,
Jason