[PATCH setup] Finish providing support for provides: and conflicts:

Ken Brown kbrown@cornell.edu
Sat Jun 23 15:10:00 GMT 2018


On 6/19/2018 8:43 AM, Ken Brown wrote:
> On 6/18/2018 1:49 PM, Ken Brown wrote:
>> [Redirecting to cygwin-apps.]
>>
>> On 6/18/2018 1:32 PM, Jon Turney wrote:
>>> On 06/06/2018 21:44, Jon Turney wrote:
>>>> On 04/04/2018 14:21, Ken Brown wrote:
>>>>> On 3/21/2018 3:38 PM, Ken Brown wrote:
>>>>>> Introduce member functions SolvableVersion::provides() and
>>>>>> SolvableVersion::conflicts().  This enables packagedb::read() to
>>>>>> access provides and conflicts lists from setup.ini.
>>>>>
>>>>> Ignore this patch.  It breaks libsolv's dependency processing.
>>>>>
>>>>
>>>> Thanks, even if it's not right, I'd completely overlooked the need 
>>>> for something like this.
>>>
>>> Do you have any details on what broke with this?  I've been trying it 
>>> and I don't notice any problems.
>>
>> No, I'm sorry.  I don't remember, and I didn't keep any notes about it.
> 
> It's coming back to me now.  I think I was testing the following 
> situation: I created an installed package A that was being updated 
> (possibly because of a command-line option).  I made A require a version 
> of a package B higher than the installed version, so that the update of 
> A should have forced an update of B.  This wasn't working reliably.  And 
> if I manually chose to keep the installed version of B, libsolv wasn't 
> reliably reporting a problem.
> 
> I'll try again to reproduce this, but it might be a few days until I can 
> get to it.

Here's a recipe for reproducing the problem:

1. Create a repository with two packages, A and B, and two versions 1-1 
and 2-1 of each.  Make A-1-1 require B>=1, and make A-2-1 require B>=2. 
The attached script does all this.

2. Run setup on this repo and install A-1-1 and B-1-1.

3. Run setup again.  It will offer to update both A and B.  Choose to 
keep B and press 'Next'.

setup built from the current HEAD correctly reports the dependency 
problem.  But if I apply my patch, then setup doesn't report the problem 
and lets me proceed to update A without updating B.

Ken
-------------- next part --------------
#!/bin/sh
arch=x86_64
mkdir -p testrepo/${arch}/release/{A,B}
pushd testrepo/${arch}/release/A
tar -Jcf A-1-1.tar.xz --files-from /dev/null
tar -Jcf A-1-1-src.tar.xz --files-from /dev/null
cat > A-1-1.hint << EOF
sdesc: "Test package A"
ldesc: "Test package A"
category: Libs
depends: B (>=1)
EOF
tar -Jcf A-2-1.tar.xz --files-from /dev/null
tar -Jcf A-2-1-src.tar.xz --files-from /dev/null
cat > A-2-1.hint << EOF
sdesc: "Test package A"
ldesc: "Test package A"
category: Libs
depends: B (>=2)
EOF
popd
pushd testrepo/${arch}/release/B
tar -Jcf B-1-1.tar.xz --files-from /dev/null
tar -Jcf B-1-1-src.tar.xz --files-from /dev/null
cat > B-1-1.hint << EOF
sdesc: "Test package B"
ldesc: "Test package B"
category: Libs
depends: cygwin
EOF
tar -Jcf B-2-1.tar.xz --files-from /dev/null
tar -Jcf B-2-1-src.tar.xz --files-from /dev/null
cat > B-2-1.hint << EOF
sdesc: "Test package B"
ldesc: "Test package B"
category: Libs
depends: cygwin
EOF
popd
cd testrepo
mksetupini --arch ${arch} --inifile=${arch}/setup.ini --releasearea=. \
	   --disable-check=missing-depended-package 
xz -c ${arch}/setup.ini > ${arch}/setup.xz


More information about the Cygwin-apps mailing list