[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