RE: Bug in setup.exe 2.194.2.24

RE: Bug in setup.exe 2.194.2.24

[Robert Collins]

> -----Original Message-----
> From: Cliff Hones [mailto:cliff@aonix.co.uk] 
> Sent: Sunday, April 21, 2002 11:55 PM

> It seems then that the buggy behaviour is present on W9X NT and W2K
but not XP.  Since the majority of Cygwin users do not 
> use XP (yet) I'd suggest that it would be a good idea for some
setup.exe developers to have access to a variety of systems
> to help avoid and debug this sort of problem in the future.

I certainly do try to test on more than one system, and I always make
alpha and betas available and ask for feedback. The simple reality
though is that I am a single individual, not a corporation with a test
lab. As such, testing on other platforms only happens when another
developer (such as Pavel or Gary or Michael or ...) makes the time to
test - and notices the fault. If someone wants to ship me a smallish
machine for using for tests, that would be neat. Short of that though...
we'll continue doing what we can.

> As a first step to investigating this, I moved my 'latest' 
> directory from under the mirror directory to the top level of 
> the local download directory, and the problem still occured.  
> So if the problem is in check_for_cached it's common to both 
> legacy and mirror directory handling.

Thanks for the detail Cliff. As a point of interest: both latest and
contrib are obsolete - and I expect setup.exe to redownload the entire
content of mirror sites. This is due to a restructuring done on
sources.redhat.com to put everythign in to /release. However the
restructuring is transparent in all other respects - which is why there
have been no trouble reports here :}.

The download process iterates over all known packages, and calls
download_one for the binary (if the binary is selected for
install/download) and source packages (likewise, only if selected). The
first thing that download_one does is call check_for_cached and returns
success if check_for_cached succeeds. Check_for_cached checks both the
non-prefixed directories, and the directories in each <known> mirror
prefix. This means that changing mirrors will cause repeated downloads,
and that selecting all the mirrors you want to use is the most efficient
approach.

Cheers,
Rob

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

Re: Bug in setup.exe 2.194.2.24

[Michael A Chase]

On Mon, 22 Apr 2002 09:19:01 +1000 Robert Collins <robert.collins@itdomain.com.au> wrote:

> > -----Original Message-----
> > From: Cliff Hones [mailto:cliff@aonix.co.uk] 
> > Sent: Sunday, April 21, 2002 11:55 PM

> The download process iterates over all known packages, and calls
> download_one for the binary (if the binary is selected for
> install/download) and source packages (likewise, only if selected). The
> first thing that download_one does is call check_for_cached and returns
> success if check_for_cached succeeds. Check_for_cached checks both the
> non-prefixed directories, and the directories in each <known> mirror
> prefix. This means that changing mirrors will cause repeated downloads,
> and that selecting all the mirrors you want to use is the most efficient
> approach.

I've tried to look into this, but it's slow going because I'm having
trouble following the process flow.  It appears that only the base
directory tree and prefix directories for the currently selected mirror
sites are checked.  That means if a file was downloaded for a mirror that
isn't selected in the current run, it won't get noticed in
check_for_cached().

Perhaps a separate class should be defined for tracking files found and
their possible package associations.  This could be used later for removing
obsolete versions of package archive files.

--
Mac :})
** I normally forward private questions to the appropriate mail list. **
Ask Smarter: http://www.tuxedo.org/~esr/faqs/smart-questions.htm
Give a hobbit a fish and he eats fish for a day.
Give a hobbit a ring and he eats fish for an age.



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

Re: Bug in setup.exe 2.194.2.24

[Cliff Hones]

Robert Collins <robert.collins@itdomain.com.au> wrote

> ...
> Thanks for the detail Cliff. As a point of interest: both latest and
> contrib are obsolete - and I expect setup.exe to redownload the entire
> content of mirror sites. This is due to a restructuring done on
> sources.redhat.com to put everythign in to /release. However the
> restructuring is transparent in all other respects - which is why there
> have been no trouble reports here :}.
>
> The download process iterates over all known packages, and calls
> download_one for the binary (if the binary is selected for
> install/download) and source packages (likewise, only if selected). The
> first thing that download_one does is call check_for_cached and returns
> success if check_for_cached succeeds. Check_for_cached checks both the
> non-prefixed directories, and the directories in each <known> mirror
> prefix. This means that changing mirrors will cause repeated downloads,
> and that selecting all the mirrors you want to use is the most efficient
> approach.

Yes - sorry, I was aware of the change.  It was indeed release that
I moved the package to.  I've since downloaded the setup source
from CVS and rebuilt it.  I was pleasantly surprised how easy
this was (once I realised the setup200202 branch was needed), and
after adding some diagnostics have so far found that the check_for_cached
calls do seem to be working ok.  Will look at download_one later.

-- Cliff


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

Re: Bug in setup.exe 2.194.2.24

[Cliff Hones]

> > First, "Download from Internet".

That should have read First, "Install from Internet"  The following
paragraph(s) should then make more sense.

> > Assuming there's already a cygwin installation present, setup should
> > examine all packages installed and compare their versions with the
> > latest setup.ini files from the mirrors (downloading these first if
> > necessary).  Any installed packages with higher current versions
> > available should be set to be upgraded by default.  Dependencies
> > must be checked, and any other necessary packages should be
> > upgraded as necessary.  Other packages should be placed in the 'keep'
> > state.
 
> "Download from Internet" shouldn't care in the least whether there is a
> Cygwin installation present or not.  It should only care about the files in
> the local directory tree. 

That was my original view - but it didn't seem to be the view of those who
responded to earlier posts.  There is an argument that you don't want
to be given, by default, downloads of all the packages you chose not to
install.  So now I'd like that as an option - either respect my current
install, or ignore it.

> Currently, if you install a file, it will then realize that version is
> present and not default to downloading it again.  If you don't install, the
> chooser doesn't know about the version you downloaded so it will keep
> downloading it until it is installed.

Exactly.  The main argument now seems to be whether this was intended
functionality, and if so, why.

-- Cliff



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

Re: Bug in setup.exe 2.194.2.24

[Michael A Chase]

On Mon, 22 Apr 2002 21:36:46 +1000 Robert Collins <robert.collins@itdomain.com.au> wrote:

> > From: Cliff Hones [mailto:cliff@aonix.co.uk] 
> > Sent: Monday, April 22, 2002 9:14 PM
>  
> > The problem seems to be that setup doesn't set these 
> > already-present packages to 'keep' or 'skip' by default, and 
> > there's no way for the user to find out which packages are in 
> > this state.
> 
> So you are suggesting that in download mode it should not offer to
> upgrade any installed packages by default? Or that it should only offer
> upgrades for installed packages without cached files?
> 
> I'll happily accept a (reasonable) patch for the second case, but the
> first case also seems counter-intuitive to me.

I think he'd be happy at this point if it simply wouldn't default to
downloading a file that is already present but not yet installed.
directory.

> > I can't actually see any advantage in re-downloading the 
> > packages *by default*.  
> 
> The point of 'download' mode is to allow downloads. If you choose not to
> install what you have downloaded, what should setup assume that means?

The download process should probably not even look at the currently
installed status of packages when deciding keep/skip/version in the choose
screen, just what files it found in the local directory tree.

I am working on a class design that could be used in choose.cc when in
download mode to make those decisions.
--
Mac :})
** I normally forward private questions to the appropriate mail list. **
Ask Smarter: http://www.tuxedo.org/~esr/faqs/smart-questions.htm
Give a hobbit a fish and he eats fish for a day.
Give a hobbit a ring and he eats fish for an age.



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

Re: Bug in setup.exe 2.194.2.24

[Michael A Chase]

On Mon, 22 Apr 2002 13:55:41 +0100 Cliff Hones <cliff@aonix.co.uk> wrote:

> Robert Collins wrote:
> > So you are suggesting that in download mode it should not offer to
> > upgrade any installed packages by default? Or that it should only offer
> > upgrades for installed packages without cached files?
> 
> The latter (approx) .  I view it as offering downloads - not upgrades -
> in download mode. (See below)
> 
> > I'll happily accept a (reasonable) patch for the second case, but the
> > first case also seems counter-intuitive to me.
> > ...
> > I'd like to remove the re-download facility completely. If a package
> > file is corrupt, delete the local copy and then run setup. This makes
> > setup simpler, for little cost. Setup won't keep partial files anyway,
> > so the only form of corruption has to be network transit problems, and
> > GPG signing would solve that too, and allow setup to detect and remove
> > corrupt packages automatically.
> 
> Ok - I'm prepared to be shot down in flames :-).  Here's what I'd
> like to see setup do - and I hope this is intuitive and reasonably
> compatible with current behaviour.  Apologies for the length...
> 
> First, "Download from Internet".
> 
> Assuming there's already a cygwin installation present, setup should
> examine all packages installed and compare their versions with the
> latest setup.ini files from the mirrors (downloading these first if
> necessary).  Any installed packages with higher current versions
> available should be set to be upgraded by default.  Dependencies
> must be checked, and any other necessary packages should be
> upgraded as necessary.  Other packages should be placed in the 'keep'
> state.

"Download from Internet" shouldn't care in the least whether there is a
Cygwin installation present or not.  It should only care about the files in
the local directory tree. 

Currently, if you install a file, it will then realize that version is
present and not default to downloading it again.  If you don't install, the
chooser doesn't know about the version you downloaded so it will keep
downloading it until it is installed.

> Also, a "purge local directory" option would be wonderful.

We are working on the infrastructure needed for it.

--
Mac :})
** I normally forward private questions to the appropriate mail list. **
Ask Smarter: http://www.tuxedo.org/~esr/faqs/smart-questions.htm
Give a hobbit a fish and he eats fish for a day.
Give a hobbit a ring and he eats fish for an age.



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

Re: Bug in setup.exe 2.194.2.24

[Cliff Hones]

Robert Collins wrote:
> So you are suggesting that in download mode it should not offer to
> upgrade any installed packages by default? Or that it should only offer
> upgrades for installed packages without cached files?

The latter (approx) .  I view it as offering downloads - not upgrades -
in download mode. (See below)

> I'll happily accept a (reasonable) patch for the second case, but the
> first case also seems counter-intuitive to me.
> ...
> I'd like to remove the re-download facility completely. If a package
> file is corrupt, delete the local copy and then run setup. This makes
> setup simpler, for little cost. Setup won't keep partial files anyway,
> so the only form of corruption has to be network transit problems, and
> GPG signing would solve that too, and allow setup to detect and remove
> corrupt packages automatically.

Ok - I'm prepared to be shot down in flames :-).  Here's what I'd
like to see setup do - and I hope this is intuitive and reasonably
compatible with current behaviour.  Apologies for the length...

First, "Download from Internet".

Assuming there's already a cygwin installation present, setup should
examine all packages installed and compare their versions with the
latest setup.ini files from the mirrors (downloading these first if
necessary).  Any installed packages with higher current versions
available should be set to be upgraded by default.  Dependencies
must be checked, and any other necessary packages should be
upgraded as necessary.  Other packages should be placed in the 'keep'
state.

The local directory should be scanned for required packages, and any
not present should be downloaded and placed in the local directory.
Assuming all downloads worked, the required uninstalls/installs
should be done.

[I think this is essentially what setup does now.]

If there's no Cygwin installation initially, setup should set
the base packages (only) plus dependencies for install.

Other complications/wbnif's:

   . If the user has previously uninstalled base packages or dependencies,
     should setup remember this, or forcibly select them for reinstallation?
   . setup should remember whether the user selected experimental
     packages, and offer to upgrade these to their latest test version.
   . Should setup downgrade packages (or at least flag a suggestion)
     if the setup.ini file indicates the current version is lower
     than the installed one?
   . There should be an option to show packages added to the distribution
     since the user made the previous (or original?) install, since he
     may not have made a conscious decision to exclude them from his
     installation.
   . If there are versions in the local directory which are not listed
     in the setup.ini files, should they be offered?  [Could be useful for
     someone who likes to keep his favourite old version which has worked
     for years, and for private packages.]

Next, "Install from local directory".

This should be very similar to the above.  No internet access should
be performed, so the current setup.ini files have to be trusted.
When working out what packages to upgrade by default, setup should
check that they are actually present in the local directory, and
if not, not offer them for upgrade by default.  If the user selects
any packages which are not present, or dependency checking introduces
non-present packages, setup should flag this and refuse to continue
until the user addresses the problem.

wbnif:

   . setup could flag new packages or packages which have a more
     recent version but which are not present in the local directory.

Finally, "Download from Internet".

New setup.ini files should be fetched from the mirror(s) if necessary.
The same processing as in "Install from Internet" should be carried out
to establish packages to upgrade.  Any already present in the local
directory should be changed to "keep".

I would also like a new option in this mode which effectively
says "ignore the current installation (if any)".  In this mode
the packages in the local directory, rather than those currently
installed, should be taken as the starting point.  So you
will be offered by default any upgrades to packages which have
previously been downloaded.

The user should be allowed more flexibility in this mode as to what gets
downloaded.  e.g. he should be allowed to deselect dependencies.

In all the above modes, the user should have a pick mechanism as
at present to adjust the default offerings.  In "download from
internet" and "install from internet" the offerings should be based
on the setup.ini files (possibly with older and extra local packages
included too).  In "Install from local directory" only the packages
actually present should be selectable.

There should also be an easy way to get a display of all possible
upgrades/additions.  I don't mean a way to ask for all packages
to be downloaded/installed - I'd rather have a list of packages
I haven't got so I can then go through and pick one or two to try.
Maybe that's already possible, but I haven't found out how to do it
yet.

Also, a "purge local directory" option would be wonderful.

Now I have a development environment set up I may take a look
to see what would be involved in implementing some of this
(though I'd imagine the setup experts would know better).

-- Cliff



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

RE: Bug in setup.exe 2.194.2.24

[Robert Collins]

> -----Original Message-----
> From: Cliff Hones [mailto:cliff@aonix.co.uk] 
> Sent: Monday, April 22, 2002 9:14 PM
 
> The problem seems to be that setup doesn't set these 
> already-present packages to 'keep' or 'skip' by default, and 
> there's no way for the user to find out which packages are in 
> this state.

So you are suggesting that in download mode it should not offer to
upgrade any installed packages by default? Or that it should only offer
upgrades for installed packages without cached files?

I'll happily accept a (reasonable) patch for the second case, but the
first case also seems counter-intuitive to me.
 
> I can't actually see any advantage in re-downloading the 
> packages *by default*.  

The point of 'download' mode is to allow downloads. If you choose not to
install what you have downloaded, what should setup assume that means?

> This is very unhelpful if one download failed to complete, 
> and you just want to re-fetch what hadn't been transferred on 
> the previous run.

There is a lot that setup does that needs to be more persistent. It
needs the ability to hold packages (ie 'do not offer to upgrade
autoconf'), and much more.
 
> Also, does the current implementation 
> mean that I won't be informed of a newly-added package by default?

Yes.
 
> And even cgf and the implementors now seem undecided as 
> to what should be happening.  

You do realise that that includes me I hope :}.

> So can I ask for 
> the design decision to be re-addressed?  I'd like to hear 
> what the arguments in favour of the current mechanism are.

I'd like to remove the re-download facility completely. If a package
file is corrupt, delete the local copy and then run setup. This makes
setup simpler, for little cost. Setup won't keep partial files anyway,
so the only form of corruption has to be network transit problems, and
GPG signing would solve that too, and allow setup to detect and remove
corrupt packages automatically.

Rob

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

Re: Bug in setup.exe 2.194.2.24

[Cliff Hones]

From: "Robert Collins" <robert.collins@itdomain.com.au>
Sent: Monday, April 22, 2002 11:29 AM
> There is one additional possibility that has
> occurred to me. Setup is *designed* to redownload files in download-only
> mode. This is not my preference, but was argued over waay back. So in
> download mode, *any* choice other than 'keep' or 'skip' will result in
> the files being downloaded.
> 
> Does that tie in with the behaviour you are reporting? (I finally
> clicked to this just a few minutes ago, or I'd have made  that statement
> *ages* ago.)

Well, yes.  That's kind of what I'd assumed from the original
response to my queries - I was then trying to make the point
that I found that approach rather unintuitive, and also that
the (in my opinion) more obvious behaviour would be much more
useful for people who like to separate download from install,
and would also make setting up a 'local' directory on a
network share for installing multiple machines more straightforward.

The problem seems to be that setup doesn't set these already-present
packages to 'keep' or 'skip' by default, and there's no way for the
user to find out which packages are in this state.

I can't actually see any advantage in re-downloading the packages
*by default*.  I'd agree that one should have the option to re-download
by explicitly selecting a package, but at the moment setup selects the
package for download *because it's not installed* (on the machine doing
the download) and not because it's not present in the local directory.
It also seems wrong that two successive runs of download, with default
options, will cause packages to be re-downloaded.  This is very unhelpful
if one download failed to complete, and you just want to re-fetch what
hadn't been transferred on the previous run.

My 'intuitive' behaviour would be for setup, in download mode, to set
the packages it can see are already present to the 'keep' status.
At the moment, in download mode, setup also excludes packages which
are not currently installed (presumably on the basis that you don't
want to be bothered by offers to download packages you'd earlier taken
a conscious decision not to install).  OK, but I'd like an easy way to
overrule this.  Also, does the current implementation mean that I
won't be informed of a newly-added package by default?

Current behaviour has lead several people to report that setup has
a bug.  And even cgf and the implementors now seem undecided as to
what should be happening.  So can I ask for the design decision to
be re-addressed?  I'd like to hear what the arguments in favour of
the current mechanism are.

-- Cliff



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

RE: Bug in setup.exe 2.194.2.24

[Robert Collins]

> -----Original Message-----
> From: Cliff Hones [mailto:cliff@aonix.co.uk] 
> Sent: Monday, April 22, 2002 7:16 PM

>  I was pleasantly 
> surprised how easy this was (once I realised the setup200202 
> branch was needed), and after adding some diagnostics have so 
> far found that the check_for_cached calls do seem to be 
> working ok.  

That's good to know. There is one additional possibility that has
occurred to me. Setup is *designed* to redownload files in download-only
mode. This is not my preference, but was argued over waay back. So in
download mode, *any* choice other than 'keep' or 'skip' will result in
the files being downloaded.

Does that tie in with the behaviour you are reporting? (I finally
clicked to this just a few minutes ago, or I'd have made  that statement
*ages* ago.)

Rob

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

Re: Bug in setup.exe 2.194.2.24

[Cliff Hones]

Robert,

It seems then that the buggy behaviour is present on W9X NT and
W2K but not XP.  Since the majority of Cygwin users do not use XP
(yet) I'd suggest that it would be a good idea for some setup.exe
developers to have access to a variety of systems to help avoid
and debug this sort of problem in the future.

FYI, here's another scenario which shows up the problem
(tried on a W98SE system, but on previous experience also
likely to occur on NT4SP6).

1)  Start with a Cygwin-free machine
    [I renamed my Cygwin root directory and my registry
     key to achieve this.]

2)  Download current setup.  Run it in install from internet mode.
    Use a new empty directory for the downloads.
    Do a base installation, accepting all defaults, *except*
    for one package.  Choose any package with a 'previous' version,
    and select that instead of the current. {I chose bash-2.05a-2.]

3)  Now run setup in "download from internet" mode.  It should
    notice the out-of-date package, and by default offer to
    download it.  Accept this, and let it download.

4)  Repeat 3.  setup should spot that you've now downloaded
    the later version (but not installed it) and not offer
    to download it again.  On my box it downloads it
    again by default.

As a first step to investigating this, I moved my 'latest'
directory from under the mirror directory to the top
level of the local download directory, and the problem still
occured.  So if the problem is in check_for_cached it's
common to both legacy and mirror directory handling.

-- Cliff

>From: "Robert Collins" <robert.collins@itdomain.com.au>
>
> > From: Gerrit P. Haase [mailto:gp@familiehaase.de] 
> > > And I *stil* cannot reproduce it. Setup detects the local 
> > files *every 
> > > single time*.
> > 
> > what system are you on?
> > I have problems on Win2000 and WinNT4.
> > 
> > Say, you *install* everything you need from the release using 
> > the 'current' (default setting) including some packages where 
> > a 'test' version is available (autoconf, automake).
> > 
> > Now start Setup (Download only mode) again, click one time on 
> > 'View' to see the full list and choose 'Exp' from the 
> > radiobuttons.  All what is present in setup.ini as test 
> > (experimental) gets downloaded (if it doesn't default to 
> > skip), regardless if it already present in your archive 
> > (repository) or not .
> > 
> > Now repeat it, Setup will download everything again. 
> 
> No, it doesn't. That's the point - I can't repeat this (with the
> setup200202 branch - the released setup). I suggest you roll your own
> and debug it.
> Start with download.cc:check_for_cached.




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

RE: Bug in setup.exe 2.194.2.24

[Robert Collins]

> -----Original Message-----
> From: Gerrit P. Haase [mailto:gp@familiehaase.de] 
> Sent: Sunday, April 21, 2002 6:20 PM
> To: cygwin@cygwin.com
> Subject: Re: Bug in setup.exe 2.194.2.24
> 
> 
> Hallo Robert,
> 
> > And I *stil* cannot reproduce it. Setup detects the local 
> files *every 
> > single time*.
> 
> what system are you on?
> I have problems on Win2000 and WinNT4.
> 
> Say, you *install* everything you need from the release using 
> the 'current' (default setting) including some packages where 
> a 'test' version is available (autoconf, automake).
> 
> Now start Setup (Download only mode) again, click one time on 
> 'View' to see the full list and choose 'Exp' from the 
> radiobuttons.  All what is present in setup.ini as test 
> (experimental) gets downloaded (if it doesn't default to 
> skip), regardless if it already present in your archive 
> (repository) or not .
> 
> Now repeat it, Setup will download everything again. 

No, it doesn't. That's the point - I can't repeat this (with the
setup200202 branch - the released setup). I suggest you roll your own
and debug it.

Start with download.cc:check_for_cached.

Rob

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

Re: Bug in setup.exe 2.194.2.24

[Gerrit P. Haase]

Hallo Robert,

> And I *stil* cannot reproduce it. Setup detects the local files *every
> single time*.

what system are you on?
I have problems on Win2000 and WinNT4.

Say, you *install* everything you need from the release using the 'current'
(default setting) including some packages where a 'test' version is available
(autoconf, automake).

Now start Setup (Download only mode) again, click one time on 'View' to see
the full list and choose 'Exp' from the radiobuttons.  All what is present in
setup.ini as test (experimental) gets downloaded (if it doesn't default to
skip), regardless if it already present in your archive (repository) or not .

Now repeat it, Setup will download everything again.
release\autoconf\autoconf-devel
$ ls -l
total 625
-rwxrwxrwx    1 Administ Domänen-   467004 Apr 21 08:04 autoconf-devel-2.52-4.tar.bz2
-rwxrwxrwx    1 Administ Domänen-   172032 Apr 21 08:18 autoconf-devel-2.52-4.tar.bz2.tmp


Gerrit
-- 
=^..^=


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

RE: Bug in setup.exe 2.194.2.24

[Robert Collins]

> -----Original Message-----
> From: Christopher Faylor [mailto:cgf@redhat.com] 
> Sent: Saturday, April 20, 2002 10:16 AM
> To: cygwin@cygwin.com
> Subject: Re: Bug in setup.exe 2.194.2.24
> 
> 
> On Sat, Apr 20, 2002 at 09:31:02AM +1000, Robert Collins wrote:
> >
> >
> >> -----Original Message-----
> >> From: Cliff Hones [mailto:cliff@aonix.co.uk]
> >> Sent: Saturday, April 20, 2002 9:10 AM
> >
> >> Since noone acknowledged it was a bug I've been assuming it was a
> >(rather strange to me) design feature.
> >
> >Actually, I acknowledged it as a bug, but one I couldn't 
> repeat until I 
> >was given an exact recipe on cygwin-apps. I've jet to track 
> it down and 
> >squash it though.

And I *stil* cannot reproduce it. Setup detects the local files *every
single time*.

The only thing I can think of is platform: Can anyone reproduce the bug
on windows XP? If so, please please please tell me how.

Otherwise, I'll forge on ahead with getting a new HEAD tidyup done,
including the URL class that Pavel worked quite hard on, that will allow
some normalisations - and may be able to fix the bug. (The only thing I
can see that might cause it is that the file paths look like
d:\foo\bar/release/package/packagefile, which could potentially confuse
the MSVCRT library..

Rob

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

Re: Bug in setup.exe 2.194.2.24

[Christopher Faylor]

On Sat, Apr 20, 2002 at 09:31:02AM +1000, Robert Collins wrote:
>
>
>> -----Original Message-----
>> From: Cliff Hones [mailto:cliff@aonix.co.uk] 
>> Sent: Saturday, April 20, 2002 9:10 AM
>
>> Since noone acknowledged it was a bug I've been assuming it was a
>(rather strange to me) design feature.
>
>Actually, I acknowledged it as a bug, but one I couldn't repeat until I
>was given an exact recipe on cygwin-apps. I've jet to track it down and
>squash it though.

Actually, now that I think of it maybe I *broke* it rather than fixed it
a few revisions ago.

cgf

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

Re: Bug in setup.exe 2.194.2.24

[Christopher Faylor]

On Fri, Apr 19, 2002 at 04:17:01PM -0700, Michael A Chase wrote:
>On Fri, 19 Apr 2002 18:01:34 -0400 Christopher Faylor <cgf@redhat.com> wrote:
>>However, if Robert indicates that this is not the desired behavior then
>>maybe someone else (*cough*, Michael, *cough*) might have time to look
>>into this?
>
>I'll look into it this evening.  Not sure if I'll be able to figure it
>out though.  I seem to have trouble leaving the old procedural
>paradigm.

Thanks.  Looks like my clever subliminal hint worked.

I obviously didn't mean to imply that Robert couldn't or wouldn't look
into this but I know he's been busy...

cgf

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

RE: Bug in setup.exe 2.194.2.24

[Robert Collins]

> -----Original Message-----
> From: Cliff Hones [mailto:cliff@aonix.co.uk] 
> Sent: Saturday, April 20, 2002 9:10 AM

> Since noone acknowledged it was a bug I've been assuming it was a
(rather strange to me) design feature.

Actually, I acknowledged it as a bug, but one I couldn't repeat until I
was given an exact recipe on cygwin-apps. I've jet to track it down and
squash it though.

Rob

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

RE: Bug in setup.exe 2.194.2.24

[Robert Collins]

> -----Original Message-----
> From: Christopher Faylor [mailto:cgf@redhat.com] 
> Sent: Saturday, April 20, 2002 8:02 AM

> >> On Fri, 19 Apr 2002 18:41:04 +0100 Alan Hourihane 
> >><alanh@fairlite.demon.co.uk> wrote: I think this is because you 
> >>haven't installed the packages yet.  I think setup.exe gets the 
> >>current version information from the installed package not the 
> >>download directory.

Setup gets the version of the current installed package from the local
information - which it should.
It also gets the 'curr' package information from one or more setup.ini
files.

...

> And, (bwahaha) I don't have time to look into this myself right now.

Don't worry - I've got a little time right now and am actively hacking
cygwin&related stuff this weekend.
 
> However, if Robert indicates that this is not the desired 
> behavior 

http://cygwin.com/ml/cygwin/2002-04/msg01048.html

Rob

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

RE: Bug in setup.exe 2.194.2.24

[Lawrence W. Smith]

> From: Randall R Schulz [mailto:rrschulz@cris.com]
> Sent: Friday, April 19, 2002 9:43 PM
> To: cygwin@cygwin.com
> Subject: Re: Bug in setup.exe 2.194.2.24
> 
> 
> Chris,
> 
> At 12:38 2002-04-19, you wrote:
> >On Fri, Apr 19, 2002 at 11:28:19AM -0700, Randall R Schulz wrote:
> > >I think to generalize, the current Setup.exe offers to 
> download based on
> > >which packages are currently installed, not on which 
> packages are present
> > >in the local download area(s).
> >
> >I hate to say it but that sounds like a bug to me.  I can't 
> remember if 
> >this is new behavior, though. Is it?
> 
> 
> I hesitate to say with 100% certainty, but I'm fairly sure it 
> is new behavior.
> 
> Randall Schulz

Last 2 versions behave like that but ver 2.29 didn't just tested it.

It offers to d/l packages even if not installed whereas setup 2.194.2.22
and 24 default to skip for packages not installed.

hth

Lawrence

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

Re: Bug in setup.exe 2.194.2.24

[E]

I've noticed similar behaviour.  I always use "Download from Internet" to 
get a local disk image on a zip disk, which I can then use to update cygwin 
on several machines.  However I've sometimes got things out of sync and 
can't download local copies of the package depending on what computer I'm 
downloading from.

E.

At 06:41 PM 19/04/02 +0100, Alan Hourihane wrote:
>Hi,
>
>I'm wondering if I've found a bug in setup.exe.
>
>I'm using 2.194.2.24 and when I go through "Download from Internet"
>and download the "new" components. It downloads them fine.
>
>Next, I re-run setup.exe and I go through "Download from Internet" again,
>(but this was by accident) and it says that the same files are ready
>to be downloaded and proceeds to re-download them all again.
>
>If I "Install from Local Directory" first it clears the problem.
>
>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/

Re: Bug in setup.exe 2.194.2.24

[Michael A Chase]

On Fri, 19 Apr 2002 18:01:34 -0400 Christopher Faylor <cgf@redhat.com> wrote:

> On Fri, Apr 19, 2002 at 08:33:02PM +0100, Alan Hourihane wrote:

> >setup.exe should know what it's downloaded and not installed.
> 
> Yep.  I thought I added code to do that in the previous version but
> it's been so long that I'm not sure.
> 
> And, (bwahaha) I don't have time to look into this myself right now.
> 
> However, if Robert indicates that this is not the desired behavior
> then maybe someone else (*cough*, Michael, *cough*) might have time
> to look into this?

I'll look into it this evening.  Not sure if I'll be able to figure it out
though.  I seem to have trouble leaving the old procedural paradigm.
-- 
Mac :})
** I normally forward private questions to the appropriate mail list. **
Ask Smarter: http://www.tuxedo.org/~esr/faqs/smart-questions.htm
Give a hobbit a fish and he eats fish for a day.
Give a hobbit a ring and he eats fish for an age.



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

Re: Bug in setup.exe 2.194.2.24

[Cliff Hones]

Christopher Faylor wrote on Friday, April 19, 2002 8:38 PM:
> On Fri, Apr 19, 2002 at 11:28:19AM -0700, Randall R Schulz wrote:
> >I think to generalize, the current Setup.exe offers to download based on 
> >which packages are currently installed, not on which packages are present 
> >in the local download area(s).
> 
> I hate to say it but that sounds like a bug to me.  I can't remember if
> this is new behavior, though.  Is it?

Not so new - I've already reported this twice:

   http://sources.redhat.com/ml/cygwin/2002-03/msg01115.html 
   http://sources.redhat.com/ml/cygwin/2002-03/msg01704.html

Since noone acknowledged it was a bug I've been assuming it was
a (rather strange to me) design feature.

-- Cliff



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

Re: Bug in setup.exe 2.194.2.24

[Ilya Goldin]

"Christopher Faylor" <cgf@redhat.com> wrote in message
news:20020419193821.GC24047@redhat.com...
> On Fri, Apr 19, 2002 at 11:28:19AM -0700, Randall R Schulz wrote:
> >I think to generalize, the current Setup.exe offers to download based on
> >which packages are currently installed, not on which packages are present
> >in the local download area(s).
>
> I hate to say it but that sounds like a bug to me.  I can't remember if
> this is new behavior, though.  Is it?

That doesn't sound like new behavior (although I'm not certain). I don't
think that's a bug, though -- that sounds like useful functionality. The
problem isn't that setup bases its decision of what to download on what's
installed, it's that it doesn't ALSO base its decision on what's already
downloaded.

-jt





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

Re: Bug in setup.exe 2.194.2.24

[Christopher Faylor]

On Fri, Apr 19, 2002 at 08:33:02PM +0100, Alan Hourihane wrote:
>On Fri, Apr 19, 2002 at 11:22:08AM -0700, Michael A Chase wrote:
>> On Fri, 19 Apr 2002 18:41:04 +0100 Alan Hourihane <alanh@fairlite.demon.co.uk> wrote:
>>I think this is because you haven't installed the packages yet.  I
>>think setup.exe gets the current version information from the installed
>>package not the download directory.
>
>This isn't the way it used to work, and shouldn't in my opinion.

I think you're right and I agree.

>setup.exe should know what it's downloaded and not installed.

Yep.  I thought I added code to do that in the previous version but
it's been so long that I'm not sure.

And, (bwahaha) I don't have time to look into this myself right now.

However, if Robert indicates that this is not the desired behavior
then maybe someone else (*cough*, Michael, *cough*) might have time
to look into this?

cgf

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

RE: Bug in setup.exe 2.194.2.24

[Robert Collins]

> -----Original Message-----
> From: Christopher Faylor [mailto:cgf@redhat.com] 
> Sent: Saturday, April 20, 2002 5:38 AM
> To: cygwin@cygwin.com
> Subject: Re: Bug in setup.exe 2.194.2.24
> 
> 
> On Fri, Apr 19, 2002 at 11:28:19AM -0700, Randall R Schulz wrote:
> >I think to generalize, the current Setup.exe offers to 
> download based 
> >on
> >which packages are currently installed, not on which 
> packages are present 
> >in the local download area(s).
> 
> I hate to say it but that sounds like a bug to me.  I can't 
> remember if this is new behavior, though.  Is it?

It's a bug.

Rob

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

Re: Bug in setup.exe 2.194.2.24

[Randall R Schulz]

Chris,

At 12:38 2002-04-19, you wrote:
>On Fri, Apr 19, 2002 at 11:28:19AM -0700, Randall R Schulz wrote:
> >I think to generalize, the current Setup.exe offers to download based on
> >which packages are currently installed, not on which packages are present
> >in the local download area(s).
>
>I hate to say it but that sounds like a bug to me.  I can't remember if 
>this is new behavior, though. Is it?


I hesitate to say with 100% certainty, but I'm fairly sure it is new behavior.

Randall Schulz


>cgf


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

Re: Bug in setup.exe 2.194.2.24

[Christopher Faylor]

On Fri, Apr 19, 2002 at 11:28:19AM -0700, Randall R Schulz wrote:
>I think to generalize, the current Setup.exe offers to download based on 
>which packages are currently installed, not on which packages are present 
>in the local download area(s).

I hate to say it but that sounds like a bug to me.  I can't remember if
this is new behavior, though.  Is it?

cgf

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

Re: Bug in setup.exe 2.194.2.24

[Alan Hourihane]

On Fri, Apr 19, 2002 at 11:22:08AM -0700, Michael A Chase wrote:
> On Fri, 19 Apr 2002 18:41:04 +0100 Alan Hourihane <alanh@fairlite.demon.co.uk> wrote:
> 
> > I'm using 2.194.2.24 and when I go through "Download from Internet"
> > and download the "new" components. It downloads them fine.
> > 
> > Next, I re-run setup.exe and I go through "Download from Internet" again,
> > (but this was by accident) and it says that the same files are ready
> > to be downloaded and proceeds to re-download them all again.
> 
> I think this is because you haven't installed the packages yet.  I think
> setup.exe gets the current version information from the installed
> package not the download directory.

This isn't the way it used to work, and shouldn't in my opinion.

setup.exe should know what it's downloaded and not installed.

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/

Re: Bug in setup.exe 2.194.2.24

[Randall R Schulz]

Alan,

I was about to send in a similar report yesterday evening.

I think to generalize, the current Setup.exe offers to download based on 
which packages are currently installed, not on which packages are present 
in the local download area(s).

I say this because even though I have a full set of packages in my download 
area, including all source packages, I only routinely install the binary 
counterparts. When I run Setup.exe for download, it lists "n/a" for all the 
installed binary packages but presents a (blank / unchecked) check-box in 
all the source code positions.

I don't know about you, Alan, but I still have the vast preponderance of 
packages (488 package archive files) are in the old "latest" and "contrib" 
directories and only the few from the past week or so (22) in the new, 
mirror-separated directories.

Randall Schulz
Mountain View, CA USA


At 10:41 2002-04-19, Alan Hourihane wrote:
>Hi,
>
>I'm wondering if I've found a bug in setup.exe.
>
>I'm using 2.194.2.24 and when I go through "Download from Internet" and 
>download the "new" components. It downloads them fine.
>
>Next, I re-run setup.exe and I go through "Download from Internet" again, 
>(but this was by accident) and it says that the same files are ready to be 
>downloaded and proceeds to re-download them all again.
>
>If I "Install from Local Directory" first it clears the problem.
>
>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/

Re: Bug in setup.exe 2.194.2.24

[Michael A Chase]

On Fri, 19 Apr 2002 18:41:04 +0100 Alan Hourihane <alanh@fairlite.demon.co.uk> wrote:

> I'm using 2.194.2.24 and when I go through "Download from Internet"
> and download the "new" components. It downloads them fine.
> 
> Next, I re-run setup.exe and I go through "Download from Internet" again,
> (but this was by accident) and it says that the same files are ready
> to be downloaded and proceeds to re-download them all again.

I think this is because you haven't installed the packages yet.  I think
setup.exe gets the current version information from the installed
package not the download directory.
-- 
Mac :})
** I normally forward private questions to the appropriate mail list. **
Ask Smarter: http://www.tuxedo.org/~esr/faqs/smart-questions.htm
Give a hobbit a fish and he eats fish for a day.
Give a hobbit a ring and he eats fish for an age.



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

Bug in setup.exe 2.194.2.24

[Alan Hourihane]

Hi,

I'm wondering if I've found a bug in setup.exe.

I'm using 2.194.2.24 and when I go through "Download from Internet"
and download the "new" components. It downloads them fine.

Next, I re-run setup.exe and I go through "Download from Internet" again,
(but this was by accident) and it says that the same files are ready
to be downloaded and proceeds to re-download them all again.

If I "Install from Local Directory" first it clears the problem.

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/