Re: setup with experimental libsolv-based dependency solving

2018-01-22 Thread Ken Brown

On 1/18/2018 2:15 PM, Jon Turney wrote:

On 23/11/2017 18:08, Jon Turney wrote:
I'm interested in opinion on what else is needed, before this can be 
released as 2.885


I think we're in pretty good shape except for the issue of letting the 
user see what's about to be done before we do it.  My latest attempt, 
sent a few minutes ago, may or may not be good enough.


Ken


Re: setup with experimental libsolv-based dependency solving

2018-01-18 Thread Jon Turney

On 23/11/2017 18:08, Jon Turney wrote:

On 30/10/2017 15:52, Jon Turney wrote:

On 25/10/2017 20:18, Jon Turney wrote:


This has a lot of internal changes, so could use some wider testing. 
Please test.

[...]

I've replaced these with:

[...]
I've replaced these with:

[...]

I've replaced these with:

 https://cygwin.com/setup/setup-2.884-45-gb87162.x86.exe
 https://cygwin.com/setup/setup-2.884-45-gb87162.x86_64.exe

Changes compared to setup-2.882-62-g75a2e0:

libsolv related:
- When test versions are enabled, a test version is no longer preferred 
over a non-test version with a higher version
- Default solutions are now identified in the problem report, and 
applied if the user chooses to accept them
- Meaningless '.any' arch suffix to package names is suppressed in the 
problem report
- Reinstall tasks are preserved in the chooser when going back from the 
dependency problem page


other:
- Query the user for action to take if a corrupt local file is found
- Validate package hash after download
- Rebase to include changes in 2.883 and 2.884

I'm interested in opinion on what else is needed, before this can be 
released as 2.885


Re: setup with experimental libsolv-based dependency solving

2017-11-23 Thread Jon Turney

On 30/10/2017 15:52, Jon Turney wrote:

On 25/10/2017 20:18, Jon Turney wrote:


This has a lot of internal changes, so could use some wider testing. 
Please test.

[...]

I've replaced these with:

[...]

I've replaced these with:

 https://cygwin.com/setup/setup-2.882-62-g75a2e0.x86.exe
 https://cygwin.com/setup/setup-2.882-62-g75a2e0.x86_64.exe

Changes compared to setup-2.882-49-gcc8b05:

libsolv related:
- Fix crash after incomplete download
- Handle going backwards to mirror selection correctly

other:
- Improve behaviour after download error
- Don't fatal() on unexpected early window messages
- Make 'System Proxy Settings' the default, rather than 'Direct'
- Remove support from installing from a local directory which doesn't 
contains a setup.ini file


I'm kind of tempted to tag this, stick a fork in it, and call it done, 
but I don't think we are quite there yet...


Re: setup with experimental libsolv-based dependency solving

2017-10-30 Thread Jon Turney

On 25/10/2017 20:18, Jon Turney wrote:


This has a lot of internal changes, so could use some wider testing. 
Please test.


   https://cygwin.com/setup/setup-2.882-41-g4cbfa1.x86.exe
   https://cygwin.com/setup/setup-2.882-41-g4cbfa1.x86_64.exe


I've replaced these with:

   https://cygwin.com/setup/setup-2.882-49-gcc8b05.x86.exe
   https://cygwin.com/setup/setup-2.882-49-gcc8b05.x86_64.dbg

Changes compared to 2.882-41-g4cbfa1:

- Fix installed.db getting emptied if installing from a local directory, 
which didn't contain a setup.ini

- Read epochal version numbers correctly from installed.db
- Remove the ability to install package files from a local directory 
which didn't contain a setup.ini

- Updated build instructions


Re: setup with experimental libsolv-based dependency solving

2017-10-29 Thread Jon Turney

On 28/10/2017 13:31, Ken Brown wrote:

On 10/27/2017 3:52 PM, Ken Brown wrote:

On 10/27/2017 2:57 PM, Ken Brown wrote:

On 10/25/2017 3:18 PM, Jon Turney wrote:


This has a lot of internal changes, so could use some wider testing. 
Please test.


I've just discovered a serious bug.  When installing from a local 
directory that either doesn't exist or isn't a valid repository, 
setup doesn't correctly read/write the installed file database 
(/etc/setup/installed.db).


I *think* the problem is that packagedb::read is never called.  Since 
do_local_dir returns false, LocalDirPage::OnNext takes us directly to 
the chooser.  This means that do_ini_thread never gets to the line 
that calls db.read.


Yeah, my mistake.


I just submitted two patches that seem to fix this.


Thanks.


Re: setup with experimental libsolv-based dependency solving

2017-10-27 Thread Ken Brown

On 10/27/2017 2:57 PM, Ken Brown wrote:

On 10/25/2017 3:18 PM, Jon Turney wrote:


This has a lot of internal changes, so could use some wider testing. 
Please test.


I've just discovered a serious bug.  When installing from a local 
directory that either doesn't exist or isn't a valid repository, setup 
doesn't correctly read/write the installed file database 
(/etc/setup/installed.db).


I *think* the problem is that packagedb::read is never called.  Since 
do_local_dir returns false, LocalDirPage::OnNext takes us directly to 
the chooser.  This means that do_ini_thread never gets to the line that 
calls db.read.


I could be completely wrong, but I'm throwing this out there because I 
don't have time to look at this any more right now.


Ken



Re: setup with experimental libsolv-based dependency solving

2017-10-27 Thread Ken Brown

On 10/25/2017 3:18 PM, Jon Turney wrote:


This has a lot of internal changes, so could use some wider testing. 
Please test.


I've just discovered a serious bug.  When installing from a local 
directory that either doesn't exist or isn't a valid repository, setup 
doesn't correctly read/write the installed file database 
(/etc/setup/installed.db).


Until we get this fixed, please backup installed.db before running setup 
(or just don't proceed with the installation if setup doesn't correctly 
show your installed packages).


Ken


Re: setup with experimental libsolv-based dependency solving

2017-10-26 Thread Jon Turney

On 26/10/2017 06:41, Achim Gratz wrote:

Jon Turney writes:

This has a lot of internal changes, so could use some wider
testing. Please test.


I would, except for:

/usr/lib/gcc/i686-w64-mingw32/6.4.0/../../../../i686-w64-mingw32/bin/ld: cannot 
find -lregex

Which package in Cygwin should have that?

https://cygwin.com/cgi-bin2/package-grep.cgi?grep=libregex=x86_64
You need mingw64-{x86_64,i686}-libgnurx

I'll add that to the requires for mingw64-{x86_64,i686}-libsolv.



setup with experimental libsolv-based dependency solving

2017-10-25 Thread Jon Turney


This has a lot of internal changes, so could use some wider testing. 
Please test.


  https://cygwin.com/setup/setup-2.882-41-g4cbfa1.x86.exe
  https://cygwin.com/setup/setup-2.882-41-g4cbfa1.x86_64.exe

Changes compared to 2.882:

User visible changes:

- 'Current' is replaced by 'Best' (which is slightly different in ways 
it's difficult to summarize briefly) and 'Sync' (which exposes the 
--force-current option through the UI).  These are modified by a 'Test' 
checkbox, which allows test packages to be used.
- For the handful of packages where the curr: version has a lower 
version number than some prev: (e.g. cscope), the higher version number 
is now preferred.


Internal changes:
- Uses the libsolv dependency solver, rather than a home-made one.
- Add support for 'depends: package (relation version) [...]', in a 
version section in setup.ini

- Add support for 'obsoletes:' in setup.ini, likewise

A big 'thank you' to Ken Brown for helping get this to the point where 
it's somewhat usable.