Re: setup.exe final pre-release..

[Robert Collins <rbcollins at cygwin dot com>]

On Fri, 2003-04-04 at 10:45, Alan Dobkin wrote:

> 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 not the problem, it's just how you are using the mirror :}.

> > 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....

Setup doesn't have a concept of a local mirror. It has a 'local package
dir', where it caches packages during install. The mirroring scripts
around create the same layout as setup uses for that local package dir.
Setup's needs are simple:
A setup.bz2/.ini on the mirror (ftp | http) site with correct paths and
MD5 detauls.
A local dir to work from.

the 'local' mode is designed for off-line reinstalls, *not* for
installing from a complete copy of the cygwin package site. The fact
that it allows that is a happy coincidence. I'm not about to
*deliberately* prevent that from working.

> > 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.

'local caches'. The whole point of a cache is that it's partial, and
transient. Your mirror is neither partial nor transient. I really don't
see the issue.

> > 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.  

To make this effective, the whole local cache would need to be opaque.
That would defeat your use of a mirror as a local cache. I'm not
discounting the idea, but I don't think it would achieve your goals.

> Or, a more simple workaround would be a setup option to just 
> bypass the initial scan.

At this point, I think you should grab the source and/or join
cygwin-apps at cygwin dot com dot  We'll undoubtably has out all of the options
shortly. For this specific suggestion, it has the downside of offering
an incorrect view of what you have available in your package cache.

Cheers,
Rob
-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part