On 23/10/2017 18:43, Ken Brown wrote:
On 10/23/2017 7:38 AM, Jon Turney wrote:
On 21/10/2017 21:18, Ken Brown wrote:
On 10/20/2017 6:24 PM, Ken Brown wrote:
Have you ever tested the "obsoletes:" feature of setup/libsolv? I
tried adding an "obsoletes:" line to setup.ini, and it didn't seem
to have any effect.
It seems I tested it back in May, so it might well have broken since :)
Here's a very small test repo I've been using for some tests:
http://www.dronecode.org.uk/cygwin/test/x86_64/
But yes, your patch looks like it's needed for it to work correctly...
It turns out that it *is* working (after a minor fix, attached), but
not always as I expect. Suppose A requires B and C obsoletes B.
Then the "obsoletes" statement appears to have no effect. If I
remove the dependence of A on B, then setup does propose uninstalling
B and installing C.
I guess the issue is that libsolv interprets "C obsoletes B" as
"uninstall B and install C", and it won't uninstall B while something
requires it.
The 'targeted' vs. 'untargeted' distinction is relevant here? Perhaps
we are doing the wrong one?
Maybe. I've read and re-read the discussion of this in
libsolv-bindings.txt, and I'm still not sure I understand it.
Yeah, the documentation is a bit impenetrable.
But here's a simpler case where "obsoletes" isn't working as I expect.
Using your test repo, in which A requires C and obsoletes B, I start
with none of the packages installed. I choose B for installation
(either interactively or on the command line), and B gets installed. If
I now run setup a second time, A and C get installed and B gets
uninstalled.
I expected A and C to be installed on the first run. I don't think this
has anything to do with targeted vs. untargeted, because that
distinction is only relevant for updating installed packages.
I guess I had the opposite expectation (if I ask for A to be installed,
that's what should happen, because if it insists on upgrading it behind
my back there's no way to do that...)
The actual behaviour you mention fits what's described there pretty well.