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.