Re: setup.exe final pre-release..

[Alan Dobkin <Cygwin at OmniComp dot Org>]

On 4 Apr 2003, Robert Collins wrote:

> On Fri, 2003-04-04 at 07:48, Alan Dobkin wrote:
> 
> > > > My question is this:  Why is it necessary to scan every package 
> > > > in the mirror every time setup is run against a local mirror?  
> > > > Most of the time, I am only installing a single package or a 
> > > > few updates.  It seems that setup should only check the packages 
> > > > being installed, and the rest of them should be ignored.
> > > 
> > > How do you create / maintain that local mirror. Via setup, 
> > > or via an external script of some sort?
> > 
> > Using wget, as recommended from the Cygwin web site.  I've been 
> > doing this the same way for at least a year, and it has worked 
> > fine for all previous setup releases.
> 
> And it works for this one too.

I didn't mean to imply that it doesn't work now, only that the method 
I've used to create the mirror doesn't seem to be the problem.

> It's also clearly noted that cygwins local package directory is 
> subject to change without notice - 

I understand that the directory is subject to change, but the 
nature of a mirror implies that the changes are automatically 
propogated and thus setup should still work.  Are you saying that 
setup would no longer support the same directory structure that 
is present on the current mirror sites at that same time?  Or in 
other words, that setup would use different directory structures 
for local and remote mirrors?  This doesn't make sense to me....

> you should use apache or IIS to serve out the mirror and add 
> it to your mirror selection creen in the custom URL field.
> 
> Then, setup won't check the md5's of every package.

This seems like an overly complex workaround just to preserve 
the existing functionality.  And, it has the side effect of 
creating another cache on each client system and re-downloading 
each package before it is installed.   This negates one of the 
main reasons why I set up the local mirror in the first place, 
i.e. so I could maintain a single repository on a local server 
and avoid having a bunch of local caches on each installation.

> The reason setup checks all the md5's is to ensure that what 
> it's discovered in the cache hasn't been corrupted.

That makes sense, but then there should be a way to bypass 
this check so it doesn't happen every time.  Perhaps something 
like a dirty/clean flag that filesystems use to prevent having 
to do a fsck/chkdsk every time it's mounted.  Setup could set 
this flag in its cache to dirty every time it does a download 
and then set it to clean every time the full MD5 scan is done.  

Or, a more simple workaround would be a setup option to just 
bypass the initial scan.  Doesn't setup check the MD5 sums 
when it installs the selected packages anyway?  Couldn't the 
scan to check for cache corruption be performed after the 
package selection screen, so it only affects the packages 
being installed?  At least this would cut down on the long 
initial delay and combine it with the same time-consuming 
portion where the packages are being installed.  That way 
the user only has to go get a cup of coffee once during the 
installation process instead of twice.  :-)

> There was another thread on this in cygwin-apps. Max 
> considers it a release blocker, I don't. Accordingly, 
> I said I was happy to consider patches....

I finally found this thread after a while of searching:
http://sources.redhat.com/ml/cygwin-apps/2003-03/threads.html#00443

I don't necessarily consider it a release blocker, but I 
think other users in the same boat will find it very annoying 
if there is no bypass option after this version is released.  
I agree with Max's comment that it will be the #1 complaint.

I would gladly write a patch if I had the ability to do it 
in a reasonable amount of time, but I'm sure others are set 
up to do it in a small fraction of the time it would take me.

Thanks,
Alan


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/