setup with experimental libsolv-based dependency solving

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

setup with experimental libsolv-based dependency solving

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.
Reply | Threaded
Open this post in threaded view
|

Re: setup with experimental libsolv-based dependency solving

Achim Gratz
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?


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Reply | Threaded
Open this post in threaded view
|

Re: setup with experimental libsolv-based dependency solving

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&arch=x86_64
You need mingw64-{x86_64,i686}-libgnurx

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

Reply | Threaded
Open this post in threaded view
|

Re: setup with experimental libsolv-based dependency solving

Achim Gratz
Jon Turney writes:
>> Which package in Cygwin should have that?
> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=libregex&arch=x86_64
> You need mingw64-{x86_64,i686}-libgnurx

Ah, so I can search a long time for a package with "regex".  :-)

In addition, I think the configury should check for the availability of
that library (just like it already does for libsolv).

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

Thanks.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Reply | Threaded
Open this post in threaded view
|

Re: setup with experimental libsolv-based dependency solving

Ken Brown-6
In reply to this post by Jon TURNEY
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
Reply | Threaded
Open this post in threaded view
|

Re: setup with experimental libsolv-based dependency solving

Ken Brown-6
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

Reply | Threaded
Open this post in threaded view
|

Re: setup with experimental libsolv-based dependency solving

Ken Brown-6
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.

I just submitted two patches that seem to fix this.

Ken

Reply | Threaded
Open this post in threaded view
|

Re: setup with experimental libsolv-based dependency solving

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.
Reply | Threaded
Open this post in threaded view
|

Re: setup with experimental libsolv-based dependency solving

Jon TURNEY
In reply to this post by 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
Reply | Threaded
Open this post in threaded view
|

Re: setup with experimental libsolv-based dependency solving

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...
Reply | Threaded
Open this post in threaded view
|

Re: setup with experimental libsolv-based dependency solving

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
Reply | Threaded
Open this post in threaded view
|

Re: setup with experimental libsolv-based dependency solving

Ken Brown-6
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