Setup

Setup

[Robert Collins]

Ok, final feedback and bug-killing time folk.

A big thanks to Michael, Jason, Pavel, Gary, and everyone else who has
helped make this latest incarnation of setup.exe the best yet.

Chuck, your fix is in there :}.
Chris, thank you for humouring me with regards to that... 300 line
changelogs tend to make me grumpy :}.

I've branched 'setup200202' with the string patch + Michaels' patchs +
Jason's off-by-one patch.

The version number on the new setup will be 2.194.2.x where x will be
version specific bug fixes.

No, and I really mean it this time :] wholesale changes to the branch
please. CVS HEAD is no open for development again.

Cheers,
Rob



P.S. Michael : A Changelog is a beautiful thing :}.

Patch Changelogs

[Michael A Chase]

----- Original Message -----
From: "Robert Collins" <robert.collins@itdomain.com.au>
To: <cygwin-apps@sources.redhat.com>
Sent: Monday, February 18, 2002 06:13
Subject: Setup


> I've branched 'setup200202' with the string patch + Michaels' patchs +
> Jason's off-by-one patch.
> . . .
> P.S. Michael : A Changelog is a beautiful thing :}.

Like these?

One changelog set per patch.
--
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.

2002-02-02  Michael A Chase <mchase@ix.netcom.com>

    * archive_tar.cc: Remove concat.h include.
    * archive_tar_file.cc: Remove concat.h include.
    * desktop.cc (make_link): Wrap long lines.
    (start_menu): Wrap long lines.
    (desktop_icon): Change cygpath() call to use String.
    (make_cygwin_bat): Ditto.
    (make_etc_profile): Ditto.
    (make_passwd_group): Ditto.
    (save_icon): Ditto.
    (check_desktop): Replace String::concat with String +.
    (check_startmenu): Ditto.
    (DesktopSetupPage::OnInit): Change cygpath() calls to use String.
    * download.cc (download_one): Change io_stream::mkpath_p() call to use
String.
    Wrap long lines.
    * fromcwd.cc: Remove concat.h include.
    * ini.cc (find_routine): Wrap long lines.
    * install.cc: Remove concat.h include.
    (install_one_source): Change cygpath() calls to use String.
    (do_install_thread): Ditto.
    * io_stream_cygfile.cc (io_stream_cygfile::io_stream_cygfile): Ditto.
    (io_stream_cygfile::mklink): Ditto.
    * localdir.cc: Remove concat.h include.
    * log.cc: Remove concat.h include.
    * mount.cc: Ditto.
    Move macro SLASH_P from concat.h.
    (cygpath): Make function version that takes String argument global.
    (cygpath): Remove function version that takes char* argument.
    * mount.h: Replace String cygpath(char*) with String cygpath(String).
    * nio-http.cc: Remove concat.h include.
    (retry_get): Change variable url to parameter Purl.
    Replace concat() call with String +.
    * package_db.cc: Remove concat.h include.
    (packagedb::flush): Replace concat() call with String +.
    * package_meta.cc: Remove concat.h include.
    (packagemeta::uninstall): Change cygpath() calls to use String.
    * postinstall.cc (do_postinstall): Replace concat() calls with String +.
    * script.cc: Remove concat.h include.
    (init_run_script): Change cygpath() calls to use String.
    (run_script): Ditto.
    Replace concat() call with String +.
    (try_run_script): Replace concat() calls with String +.
    * site.cc: Remove concat.h include.

2002-02-02  Michael A Chase <mchase@ix.netcom.com>

    * compress_bz.cc (compress_bz::peek): Remove log() call.
    (compress_bz::seek): Fix indentation.
    (compress_bz::~compress_bz): Remove log() call.
    * compress_gz.cc (compress_gz::peek): Ditto.
    (compress_bz::seek): Ditto.
    (compress_bz::destroy): Ditto.
    * download.cc (download_one): Replace LOG_TIMESTAMP with LOG_PLAIN.
    Change log() call to use String parameter.
    * geturl.cc (get_url_to_membuf): Ditto.
    (get_url_to_file): Ditto.
    * install.cc (uninstall_one): Replace LOG_TIMESTAMP with LOG_PLAIN.
    (replace_one): Ditto.
    (install_one_source): Ditto.
    Reindent and wrap long lines.
    (install_one): Replace char* msg with String msg.
    * io_stream.cc (io_stream::move): Change log() call to use String
parameter.
    * io_stream_cygfile.cc (io_stream_cygfile::mklink): Wrap long lines.
    (io_stream_cygfile::write): Remove log() call.
    * io_stream_file.cc: Remove log.h include.
    (io_stream_file::peek): Remove log() call.
    * localdir.cc (LocalDirPage::OnNext): Change log() call to use String
parameter.
    * log.h: Add enum loglevel value LOG_PLAIN (same as LOG_TIMESTAMP for
now).
    * main.cc (WinMain): Replace LOG_TIMESTAMP with LOG_PLAIN.
    Change log() calls to use String parameter.
    * msg.cc (mbox): Change log() call to use String parameter.
    * net.cc (NetPage::OnNext): Ditto.
    * nio-ftp.cc (ftp_line): Ditto.
    * package_meta.cc (packagemeta::uninstall): Ditto.
    Wrap long lines.
    * root.cc (RootPage::OnNext): Replace LOG_TIMESTAMP with LOG_PLAIN.
    * script.cc (run_script): Replace LOG_TIMESTAMP with LOG_PLAIN.
    Change log() calls to use String parameter.
    Change char* f2 with String f2.
    Regularlize spacing around operators.
    (try_run_script): Ditto.
    * site.cc (SitePage::OnNext): Replace LOG_TIMESTAMP with LOG_PLAIN.
    Change log() call to use String parameter.
    (SitePage::OnMessageCmd): Ditto.
    * source.cc (SourcePage::OnBack): Replace LOG_TIMESTAMP with LOG_PLAIN.

Re: Patch Changelogs

[Robert Collins]

Thanks - did I miss the original send of these?

I've left the ones I created for you in place as I don't think theres a
huge issue with them, if you think that what you've sent in should get
put into ChangeLog instead, let me know.

Rob

Re: Setup

[Brian Keener]

Robert Collins wrote:
> Ok, final feedback and bug-killing time folk.

I just built from CVS and the big thing I noticed in the past and still seems 
to be there has to do with doing an "Install from Local Directory" after doing 
the Download.  It appears the download is working fine but when I select 
Install from Local Directory if I select any package(s) for reinstall then 
setup seems to uninstall just fine but the Reinstall doesn't seem to do 
anything - my log doesn't seem to show any creations but it shows alot of 
unlinks for the removals.  I discovered this while researching another problem 
dealing with install from local directory where setup doesn't seem to install 
the last package selected for upgrade (as opposed to reinstall mentioned 
above).  It seems to download it fine or if I select install from the internet 
that also seems to work - I've been trying to debug it but my skills are 
beginner at best.  I can neither confirm or deny the upgrade problem at the 
moment but I just had the reinstall happen so I can confirm that one.

The other couple of things I've noticed are probably open for preference so I 
will throw them out for general consensus:

1) If I have a group of packages installed and I select the 
Test option to see what packages are available for in Test should all the 
packages I have installed that do not have a Test Version show Uninstall or 
should they should keep??  It is my contention that thy should show keep and 
not uninstall - unless I explicitly request uninstall.  

2) If I am doing and "Install from Local Directory" and the Source file does 
not exist in the Local path should the option for Source only or the Sources 
checkbox even be available?? It is my contention again that if the Sources 
cannot be found then the option should not exist.

Those are the few things I found - if you need a copy of my setup.log.full - 
just let me know.  I'll keep trying on the Reinstall to get a handle on what 
gives but if anyone has any clues you might want to fix it as opposed to 
waiting on me.

bk

Re: Setup

[Robert Collins]

===
----- Original Message -----
From: "Brian Keener" <bkeener@thesoftwaresource.com>


> Robert Collins wrote:
> > Ok, final feedback and bug-killing time folk.
>
> The other couple of things I've noticed are probably open for
preference so I
> will throw them out for general consensus:
>
> 1) If I have a group of packages installed and I select the
> Test option to see what packages are available for in Test should all
the
> packages I have installed that do not have a Test Version show
Uninstall or
> should they should keep??  It is my contention that thy should show
keep and
> not uninstall - unless I explicitly request uninstall.

I have emailed trying to start a discussion on this at least twice. My
contention is that this is a factor for setup.ini to take care of, not
setup.exe. It's easier to add entries than have complex logic for
removing them when they aren't appropriate.

> 2) If I am doing and "Install from Local Directory" and the Source
file does
> not exist in the Local path should the option for Source only or the
Sources
> checkbox even be available?? It is my contention again that if the
Sources
> cannot be found then the option should not exist.

Patches gratefully accepted.

Rob

Re: Setup

[Christopher Faylor]

On Tue, Feb 19, 2002 at 12:27:26PM +1100, Robert Collins wrote:
>>1) If I have a group of packages installed and I select the Test option
>>to see what packages are available for in Test should all the packages
>>I have installed that do not have a Test Version show Uninstall or
>>should they should keep??  It is my contention that thy should show
>>keep and not uninstall - unless I explicitly request uninstall.
>
>I have emailed trying to start a discussion on this at least twice.  My
>contention is that this is a factor for setup.ini to take care of, not
>setup.exe.  It's easier to add entries than have complex logic for
>removing them when they aren't appropriate.

If the question is "Should 'upset' add a dummy Test entry for every case
where there is no such thing?" then the answer, IMO, is no.  I think the
same applies for the case where an initial release of a product is
marked test.  Setting up a dummy "Current" which is the same as "Test"
would defeat the purpose of "Test".

I think that the bottom line is that setup.exe should NEVER default to
Uninstall.  Uninstall should only be on when the user specifically selects
it.  Anything else is, IMO, surprising and dangerous.

cgf

Re: Setup

[Robert Collins]

===
----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
To: <cygwin-apps@cygwin.com>
Sent: Tuesday, February 19, 2002 3:05 PM
Subject: Re: Setup


> On Tue, Feb 19, 2002 at 12:27:26PM +1100, Robert Collins wrote:

> If the question is "Should 'upset' add a dummy Test entry for every
case
> where there is no such thing?" then the answer, IMO, is no.  I think
the
> same applies for the case where an initial release of a product is
> marked test.  Setting up a dummy "Current" which is the same as "Test"
> would defeat the purpose of "Test".

For the first case, I think the answer is yes, for the second, it
*should* be no (because, as you say, it would defeat the purpose of
test).

Otherwise we need a *new* mechanism to tell setup.exe when a package is
replaced from current to test - that is that no test version exists, and
that when moving to test, the current version should be removed.

> I think that the bottom line is that setup.exe should NEVER default to
> Uninstall.  Uninstall should only be on when the user specifically
selects
> it.  Anything else is, IMO, surprising and dangerous.

I agree that the user should be warned before automated uninstalls
happen. Thats not ever been the case though in the gui.

Setup doesn't *default* to uninstall. Two things have to happen:
The user has to select Test (which means 'give me a testing
distribution').
Their has to be no valid testing version for that package.

Rob

Re: Setup

[Brian Keener]

Robert Collins wrote:
> Setup doesn't *default* to uninstall. Two things have to happen:
> The user has to select Test (which means 'give me a testing
> distribution').
> Their has to be no valid testing version for that package.

But if I select test (which means 'give me a testing package not a testing 
distribution') and the only test version available is a test version of vim 
that I want to try and everything else defaults to uninstall and I say next 
what do I have when I get done - nada - nothing and lets do it again because I 
wasn't paying attention and had no idea that setup would uninstall my entire 
system because I wanted to try one test version.

Hummmmm - sounds pretty nasty to me.

bk

Re: Setup

[Robert Collins]

===
----- Original Message -----
From: "Brian Keener" <bkeener@thesoftwaresource.com>

> But if I select test (which means 'give me a testing package not a
testing
> distribution')

No it doesn't. Clicking on a package version is how one selects per
package versions.

> and the only test version available is a test version of vim
> that I want to try and everything else defaults to uninstall and I say
next
> what do I have when I get done - nada - nothing and lets do it again
because I
> wasn't paying attention and had no idea that setup would uninstall my
entire
> system because I wanted to try one test version.
>
> Hummmmm - sounds pretty nasty to me.

Exactly why I've been raising this!

Rob

Re: Setup

[Brian Keener]

Robert Collins wrote:
> > But if I select test (which means 'give me a testing package not a
> testing
> > distribution')
> 
> No it doesn't. Clicking on a package version is how one selects per
> package versions.
>
That's where our view differs because I see the radio buttons as a way of 
selecting the maximum version I want considered and if that version does not 
exist then the default is the next version down (Test -> Current -> Prev 
depending on Radio button selected) and if the version selected is what is 
installed the default is keep and if it is not installed at all then the 
default is skip.

Re: Setup

[Robert Collins]

===
----- Original Message -----
From: "Brian Keener" <bkeener@thesoftwaresource.com>
To: <cygwin-apps@cygwin.com>
Sent: Tuesday, February 19, 2002 3:44 PM
Subject: Re: Setup


> Robert Collins wrote:
> > > But if I select test (which means 'give me a testing package not a
> > testing
> > > distribution')
> >
> > No it doesn't. Clicking on a package version is how one selects per
> > package versions.
> >
> That's where our view differs because I see the radio buttons as a way
of
> selecting the maximum version I want considered and if that version
does not
> exist then the default is the next version down (Test -> Current ->
Prev
> depending on Radio button selected) and if the version selected is
what is
> installed the default is keep and if it is not installed at all then
the
> default is skip.

Well, I'll consider a patch to setup to change it's behaviour. At the
moment no limitation of maximum version is present, regardless of the
prev/curr/test state.

Rob

Re: Setup

[Brian Keener]

Robert Collins wrote:
> > That's where our view differs because I see the radio buttons as a way
> of
> > selecting the maximum version I want considered and if that version
> does not
> > exist then the default is the next version down (Test -> Current ->
> Prev
> > depending on Radio button selected) and if the version selected is
> what is
> > installed the default is keep and if it is not installed at all then
> the
> > default is skip.
> 
> Well, I'll consider a patch to setup to change it's behaviour. At the
> moment no limitation of maximum version is present, regardless of the
> prev/curr/test state.

I catch the drift on the patches and the same with the other two we discussed.  
At one point in time when I was still submitting changes to setup, when I still 
understood the code before the major rewrite :-) - don't get me wrong this is 
good stuff - I thought we had it where Test, Curr, and Prev only set the 
maximum version we wanted to look at.  But on the down side we never had it 
fully functional where it would handle multiple versions simply because they 
existed on disk and this is a very good new feature.  I would not want to loose 
itt.

But what I do propose is that we think of Prev as the last stable version, we 
think of Current as the current stable and we think of test as a development 
version - which could be changing rapidly.  There may be any number of versions 
resident on my disk that are in between the control points and they should all 
be available for me to choose from in the chooser.  But the maintainer dictates 
via setup.ini which version is the Prev stable, Curr stable and experimental 
(Test) or any combination thereof. 

With this in mind the Prev, Curr, and Test buttons should simply set the 
maximum version (with the primary choice being the Current Stable for the 
inexperience that simply want to use the product) that I want installed of any 
given package and then I still have the ability to select any other major or 
intermediate version (these amy or may not be a Prev, Curr, or Test) for a 
package as well.  Essentially if I have the Current radio selected and a Prev 
is installed and there is a new Curr it will select that current version for 
install and if on another package I have a Test version installed and there is 
a Curr version available then it will select the current version for install 
(thus deinstalling the Test version) and if by some quirk I have a Test 
installed, the Current Radio button selected but there is no Curr version it 
will select the Prev and if there is no Prev version it will simply select keep 
(although I'm not sure I like this - but I like an uninstall option even less).

I would think we also need some mechanism (because of the ability to mix and 
match versions) to give the user the ability to select the default actions for 
all packages listed - for example: 1) I want to *keep/skip* (depending on if 
installed or not) all and then simply upgrade one or two - no matter what is 
available 2) I want to *reinstall* whatever I currently have installed - no 
matter what is available 3) I want to install *sources* for everything I have 
installed - nothing more - nothing less and the really nasty option I want to 
*uninstall* everything with a big fat warning.  I am essentially describing a 
global for the chooser that lets me pick from the standard chooser options but 
for all packages.  I can then pick and choose below that for the individual 
package.  I am sure categories will to some degree get in the way of this but I 
am sure that some workable solution could be found.

Another nice touch and clarification in chooser might be to expand the text on 
the version number in the display for those packages where I might have 5 
versions available for install.  As I am clicking through the versions on a 
given package when I get to a version that is the Prev, Curr or Test if the 
text shows this - ie 1.4.5 (Curr) or 1.4.3 (Prev) or 1.4.4.  In this case 1.4.4 
is just an available intermediate.

This is my $.02 worth and the world of setup and chooser as I see and would 
code if I could - don't get me wrong I'm still trying but the going is slow - 
got my hands in too many pots (and some have hot water) and setup is a tough 
teacher for learning C++.

Bk

Re: Setup

[Robert Collins]

----- Original Message -----
From: "Brian Keener" <bkeener@thesoftwaresource.com>

> I catch the drift on the patches and the same with the other two we
discussed.  > At one point in time when I was still submitting changes
to setup, when I still > understood the code before the major rewrite
:-)

It should be a lot easier to understand now, and it's starting to really
come together now.

> Another nice touch and clarification in chooser might be to expand the
text on
> the version number in the display for those packages where I might
have 5
> versions available for install.  As I am clicking through the versions
on a
> given package when I get to a version that is the Prev, Curr or Test
if the
> text shows this - ie 1.4.5 (Curr) or 1.4.3 (Prev) or 1.4.4.  In this
case 1.4.4 > is just an available intermediate.

Nice idea, patches accepted :} (Hint: start with the PackagePickLine
class). I've added to the TODO list.

Rob

Re: Setup

[Christopher Faylor]

On Tue, Feb 19, 2002 at 03:19:43PM +1100, Robert Collins wrote:
>
>===
>----- Original Message -----
>From: "Christopher Faylor" <cgf@redhat.com>
>To: <cygwin-apps@cygwin.com>
>Sent: Tuesday, February 19, 2002 3:05 PM
>Subject: Re: Setup
>
>
>> On Tue, Feb 19, 2002 at 12:27:26PM +1100, Robert Collins wrote:
>>If the question is "Should 'upset' add a dummy Test entry for every
>>case where there is no such thing?" then the answer, IMO, is no.  I
>>think the same applies for the case where an initial release of a
>>product is marked test.  Setting up a dummy "Current" which is the same
>>as "Test" would defeat the purpose of "Test".
>
>For the first case, I think the answer is yes, for the second, it
>*should* be no (because, as you say, it would defeat the purpose of
>test).
>
>Otherwise we need a *new* mechanism to tell setup.exe when a package is
>replaced from current to test - that is that no test version exists, and
>that when moving to test, the current version should be removed.

Ok.  We need a new mechanism.  We also need a mechanism that says
"remove this package" and I don't think that the mechanism is to just
move the package to "prev".  Maybe the mechanism is as simple as just
having a setup.hint like:

  setup.hint:
  curr uninstall "This package is now obsolete"

(wouldn't it be cool to have a "bubble" appear with the above words when
you moved the mouse cursor over the package name?)

Actually, in this case, where the package maintainer means to obviously
uninstall something, I think it is acceptable for setup.exe to do so.

>>I think that the bottom line is that setup.exe should NEVER default to
>>Uninstall.  Uninstall should only be on when the user specifically
>>selects it.  Anything else is, IMO, surprising and dangerous.
>
>I agree that the user should be warned before automated uninstalls
>happen.  Thats not ever been the case though in the gui.

I've always considered it a bug when the word "Uninstall" shows up
in the GUI and I didn't specifically click on it.

>Setup doesn't *default* to uninstall.  Two things have to happen: The
>user has to select Test (which means 'give me a testing distribution').
>Their has to be no valid testing version for that package.

If I click on Test, then a whole bunch of Installs show up on the
screen.  If you don't like the word "default" then I'll use
"automatically switch".

I don't think that setup.exe should automatically switch to Uninstall
in any circumstances unless the package maintainer has specifically
indicated that is the correct behavior.  Somehow.

When I click on test I assume it means "Give me all of the test versions".
I think it is acceptable that if there are no test versions, then every
other package shows up as "Skip".  I don't think that we should assume
that the correct behavior is Uninstall.

Actually, this is one of the things that I hate about the current way
setup works.  I don't like the Prev/Curr/Test stuff that much.  It feels
like we're overloading functionality incorrectly but I don't have a real
idea about how to fix it.

cgf

Re: Setup

[Christopher Faylor]

On Mon, Feb 18, 2002 at 11:46:01PM -0500, Christopher Faylor wrote:
>>Setup doesn't *default* to uninstall.  Two things have to happen: The
>>user has to select Test (which means 'give me a testing distribution').
>>Their has to be no valid testing version for that package.
>
>If I click on Test, then a whole bunch of Installs show up on the
                                         uninstalls
>screen.  If you don't like the word "default" then I'll use
>"automatically switch".

cgf

RE: Setup

[Gary R. Van Sickle]

> -----Original Message-----
> From: cygwin-apps-owner@cygwin.com
> [mailto:cygwin-apps-owner@cygwin.com]On Behalf Of Christopher Faylor

[snip]

> (wouldn't it be cool to have a "bubble" appear with the above words when
> you moved the mouse cursor over the package name?)
>

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Feature freeze feature freeze feature freeze ;-)

No, for Setup 3.0 or whatever the release-after-next will be numbered, I think
we almost need to have something like that.  In particular I think we need to do
the "popup-text-tooltip-when-the-description-text-goes-off-the-screen" trick,
since pretty much every description overflows the allotted real-estate.

--
Gary R. Van Sickle
Brewer.  Patriot.

Re: Setup

[Christopher Faylor]

On Wed, Feb 20, 2002 at 11:17:05PM -0600, Gary R. Van Sickle wrote:
>> -----Original Message-----
>> From: cygwin-apps-owner@cygwin.com
>> [mailto:cygwin-apps-owner@cygwin.com]On Behalf Of Christopher Faylor
>
>[snip]
>
>> (wouldn't it be cool to have a "bubble" appear with the above words when
>> you moved the mouse cursor over the package name?)
>>
>
>NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Um.  I wasn't suggesting this for this release.  I understand what feature
freeze means.

Speaking of chilling...

cgf

Re: Setup

[Robert Collins]

===
----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>

> >Otherwise we need a *new* mechanism to tell setup.exe when a package
is
> >replaced from current to test - that is that no test version exists,
and
> >that when moving to test, the current version should be removed.
>
> Ok.  We need a new mechanism.  We also need a mechanism that says
> "remove this package" and I don't think that the mechanism is to just
> move the package to "prev".  Maybe the mechanism is as simple as just
> having a setup.hint like:
>
>   setup.hint:
>   curr uninstall "This package is now obsolete"
>
> (wouldn't it be cool to have a "bubble" appear with the above words
when
> you moved the mouse cursor over the package name?)
>
> Actually, in this case, where the package maintainer means to
obviously
> uninstall something, I think it is acceptable for setup.exe to do so.

Versioned conflicts will do this, which is a wishlist feature. Someone
offered to do them, but I don't think a patch has arrived yet.

> I don't think that setup.exe should automatically switch to Uninstall
> in any circumstances unless the package maintainer has specifically
> indicated that is the correct behavior.  Somehow.

I agree. My point has been (from the beginning) about *where* that
intent gets indicated.

Rob

Re: Setup

[Christopher Faylor]

On Sun, Feb 24, 2002 at 10:04:32PM +1100, Robert Collins wrote:
>> I don't think that setup.exe should automatically switch to Uninstall
>> in any circumstances unless the package maintainer has specifically
>> indicated that is the correct behavior.  Somehow.
>
>I agree. My point has been (from the beginning) about *where* that
>intent gets indicated.

No, you're not agreeing if you think that a setup.ini file can be
crafted in such a way that an "Uninstall" will show up without the
package maintainer explicitly somehow saying "I want this package to
be uninstalled".  And, not making a test version of a package available
is not "explicit".

cgf

Re: Setup

[Brian Keener]

Robert Collins wrote:
> I have emailed trying to start a discussion on this at least twice. My
> contention is that this is a factor for setup.ini to take care of, not
> setup.exe. It's easier to add entries than have complex logic for
> removing them when they aren't appropriate.
>
So what you're saying is just looking at Current vs Previous - if there was no 
setup.ini entry for current and there was only an entry for previous then with 
the default display set to current the selected default action for the 
theoretical package would be uninstall (just as I saw on the Test) - correct?

And in addition if as a maintainer I didn't want this to happen then I should 
make sure I have a prev,curr and test in setup.ini even if they all are the 
same file name.

This bears the question (if my previous assumption is correct) what if my 
setup.ini has a prev, curr, and test file defined but I am doing an "Install 
from Local Directory" and the test version does not exist on my system.  I 
would assume that since I defined a test and even though is does not exist that 
my default action would be keep - true?

bk

Re: Setup

[Robert Collins]

===
----- Original Message -----
From: "Brian Keener" <bkeener@thesoftwaresource.com>
To: "Robert Collins" <robert.collins@itdomain.com.au>;
<cygwin-apps@sources.redhat.com>
Sent: Tuesday, February 19, 2002 3:18 PM
Subject: Re: Setup


> Robert Collins wrote:
> > I have emailed trying to start a discussion on this at least twice.
My
> > contention is that this is a factor for setup.ini to take care of,
not
> > setup.exe. It's easier to add entries than have complex logic for
> > removing them when they aren't appropriate.
> >
> So what you're saying is just looking at Current vs Previous - if
there was no
> setup.ini entry for current and there was only an entry for previous
then with
> the default display set to current the selected default action for the
> theoretical package would be uninstall (just as I saw on the Test) -
correct?

No. There is a pretty big difference (IMO) between prev, current and
test.
Prev - distribution with old versions kept around for convenience sake.
Current - distribution with the latest stable versions.
Test - distribution with versions where things break, major changes
occur etc.

Any version of a package can be selected without the use of the
prev/curr/test buttons - they are designed to make wholesale changes to
the environment.

Prev-Current should be minor - to allow backing out of a minor revision
change that introduced a new bug.

Current-Test *may* be very major.

we have currently in the 'default' picking logic:
packageversion * trustp (trusts const t) const
{
  return t == TRUST_PREV ? (prev ? prev : (curr ? curr : installed))
       : t == TRUST_CURR ? (curr ? curr : installed)
       : exp;
}

IOW, for prev, choose an explicit prev, then a current, and then an
installed.
for current, choose a current, and then an installed.
for test (exp), choose the explicit experimental version.

> And in addition if as a maintainer I didn't want this to happen then I
should
> make sure I have a prev,curr and test in setup.ini even if they all
are the
> same file name.

That is one way, it is very manual however. What I'm suggesting is that
*in the absence* of prev:,curr:,test: tags in setup.hint, that upset
always generate a
[test] entry - just like it automatically generates a [prev] entry when
there are two versions in the directory.

> This bears the question (if my previous assumption is correct) what if
my
> setup.ini has a prev, curr, and test file defined but I am doing an
"Install
> from Local Directory" and the test version does not exist on my
system.  I
> would assume that since I defined a test and even though is does not
exist that > my default action would be keep - true?

I'm not sure :}. I'm not sure that that would be appropriate behaivour
in the general case. We really need versioned conflicts: and depends:
lines to make this all work correctly.

Rob

Re: Setup

[Robert Collins]

===
----- Original Message -----
From: "Brian Keener" <bkeener@thesoftwaresource.com>
To: <cygwin-apps@sources.redhat.com>
Sent: Tuesday, February 19, 2002 8:06 AM
Subject: Re: Setup


> Robert Collins wrote:
> > Ok, final feedback and bug-killing time folk.
>
> I just built from CVS and the big thing I noticed in the past and
still seems
> to be there has to do with doing an "Install from Local Directory"
after doing

I've found the cause, and stopped the silent failure (fix is in
setup200202). I'm working on correcting the behaviour now.

Rob

Re: Setup

[Robert Collins]

===
----- Original Message ----- 
From: "Robert Collins" <robert.collins@itdomain.com.au>

> I've found the cause, and stopped the silent failure (fix is in
> setup200202). I'm working on correcting the behaviour now.

And a complete fix is in CVS now.

Rob

Re: Setup

[Brian Keener]

Robert Collins wrote:
> And a complete fix is in CVS now.
>

I just tried setup from cvs and rebuilt and I still get the null file on the 
last file I try to install from my local directory.  Actually it was a 
reinstall of zlib and it failed with the null error and then when I went back 
into setup it showed it as a new install and when I selected to install it - I 
still got the Null error.  I then went and did an install from the internet and 
zlib showed as needing to be installed and then installed just fine.

It might be something with my version since I did a full cvs update but I 
didnot get the patch for test to default to keep if already installed.  That 
appears to have been applied to the branch and so I applied it to mine 
manually.  So maybe something else got skipped as well.

Bk

Re: Setup

[Robert Collins]

===
----- Original Message -----
From: "Brian Keener" <bkeener@thesoftwaresource.com>
To: <cygwin-apps@sources.redhat.com>
Sent: Friday, February 22, 2002 12:53 PM
Subject: Re: Setup


> Robert Collins wrote:
> > And a complete fix is in CVS now.
> >
>
> I just tried setup from cvs and rebuilt and I still get the null file
on the
> last file I try to install from my local directory.  Actually it was a
> reinstall of zlib and it failed with the null error and then when I
went back
> into setup it showed it as a new install and when I selected to
install it - I
> still got the Null error.  I then went and did an install from the
internet and
> zlib showed as needing to be installed and then installed just fine.
>
> It might be something with my version since I did a full cvs update
but I
> didnot get the patch for test to default to keep if already installed.
That
> appears to have been applied to the branch and so I applied it to mine
> manually.  So maybe something else got skipped as well.

What TAG did you build from? setup200202 works fine for me, and doesn't
uninstall installed packages when test is selected. Like Chris I feel
the solution is wrong, but I can't articulate (yet) how the model is
wrong, and so I've followed the (apparent) consensus.

If you're looking at HEAD, bugfixes are going in there as well, but the
test mode behaviour is cosmetic IMO, as opposed to the silent failure
from local directories!

Rob

Re: Setup

[Brian Keener]

Robert Collins wrote:
> What TAG did you build from? setup200202 works fine for me, and doesn't
> uninstall installed packages when test is selected. Like Chris I feel

Built from HEAD - which is why I guess the fix for the Test/Uninstall wasn't 
there, but once I applied the patch for the Test/Uninstall fix to my copy then 
Test/Keep as opposed to Test/Uninstall works great.

> he solution is wrong, but I can't articulate (yet) how the model is
> wrong, and so I've followed the (apparent) consensus.

I don't know why that doesn't seem right to you.  It appears to me that I will 
never have an installation that is comprised solely of all Test packages.  I 
will always be testing a few packages but the bulk of the system will be the 
current Stable versions.  That would naturally be the nature of the beast as 
working with all test versions would be to cumbersome to find where something 
was failing.  That said if I have to work with Current Stable versions while I 
am testing experimental packages why would I want the default on the installed 
packages to be Uninstall - I would want to keep those packages so I would still 
have a working system. I also do not particularly want to click on 20 packages 
to say keep these instead of uninstalling.  Makes perfect sense to me.

As to the NULL file when reinstalling - that patch was applied to HEAD and not 
just setup200202 wasn't it or was the full fix only committed to setup200202? I 
do seem to have that fix (since I get the message about the Null file - no 
silent failure) or at least part of it but it does still seem to have a problem 
with the last file that you might have selected.  At first I thought it only 
had the problem if for some reason setup determined it needed the method 
replace_one but even after it removed zlib when I said reinstall and then I 
tried to just install zlib it still failed and would not install zlib.  It just 
doesn't seem to like the last file.

Re: Setup

[Christopher Faylor]

On Fri, Feb 22, 2002 at 08:48:04PM -0500, Brian Keener wrote:
>Robert Collins wrote:
>> What TAG did you build from? setup200202 works fine for me, and doesn't
>> uninstall installed packages when test is selected. Like Chris I feel
>
>Built from HEAD - which is why I guess the fix for the Test/Uninstall wasn't 
>there, but once I applied the patch for the Test/Uninstall fix to my copy then 
>Test/Keep as opposed to Test/Uninstall works great.
>
>> he solution is wrong, but I can't articulate (yet) how the model is
>> wrong, and so I've followed the (apparent) consensus.
>
>I don't know why that doesn't seem right to you.

I think Robert was saying that the whole prev/curr/test model feels wrong.

But, perhaps uncharacteristically, neither of us has an opinion on how to
change it.  :-)

cgf

Re: Setup

[Robert Collins]

----- Original Message -----
From: "Brian Keener" <bkeener@thesoftwaresource.com>

> > he solution is wrong, but I can't articulate (yet) how the model is
> > wrong, and so I've followed the (apparent) consensus.
>
> I don't know why that doesn't seem right to you.  It appears to me
that I will
> never have an installation that is comprised solely of all Test
packages.

[Devil's advocate mode on] Why not? Debian has one, and it works great.

> I
> will always be testing a few packages but the bulk of the system will
be the
> current Stable versions.  That would naturally be the nature of the
beast as
> working with all test versions would be to cumbersome to find where
something
> was failing.  That said if I have to work with Current Stable versions
while I
> am testing experimental packages why would I want the default on the
installed
> packages to be Uninstall - I would want to keep those packages so I
would still > have a working system. I also do not particularly want to
click on 20 packages
> to say keep these instead of uninstalling.  Makes perfect sense to me.

I have never said that I want every package to uninstall. I have
explained that that behaviour is a SIDE EFFECT of the behaviour I want,
which is for system smarts about the intention of maintainers to be
removed from setup, and made explicit. This gives greater flexability,
and the potential for quicker changes - because setup.exe won't be part
of the change process.

However, that was not what I was referring to in saying that the
solution is wrong. I mean that the whole x= prev/curr/test y=version
model is wrong, and because THAT is wrong, the GUI and engine behaviour
is confusing (because it has multiple, reasonable interpretations).

> As to the NULL file when reinstalling - that patch was applied to HEAD
and not
...
> tried to just install zlib it still failed and would not install zlib.
It just > doesn't seem to like the last file.

I'll have a look-see.

Rob

Re: Setup

[Brian Keener]

Robert Collins wrote:
> > As to the NULL file when reinstalling - that patch was applied to HEAD
> and not
> ...
> > tried to just install zlib it still failed and would not install zlib.
> It just > doesn't seem to like the last file.
> 
> I'll have a look-see.
>

I tried the setup-20020225.exe and also updated my sources from cvs HEAD and 
this problem appears to be fixed.  I installed one and only one file  as a 
reinstall and it appeared to work just like it should.

It also appears (and I haven't looked real close yet) that you have improved 
what packages show and do not show depending on what installation/download 
method I chose.

Good job.

Bk