* [setup topic/libsolv] Does "obsoletes:" work? @ 2017-10-20 22:25 Ken Brown 2017-10-21 20:19 ` Ken Brown 0 siblings, 1 reply; 8+ messages in thread From: Ken Brown @ 2017-10-20 22:25 UTC (permalink / raw) To: cygwin-apps Jon, 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. Ken ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [setup topic/libsolv] Does "obsoletes:" work? 2017-10-20 22:25 [setup topic/libsolv] Does "obsoletes:" work? Ken Brown @ 2017-10-21 20:19 ` Ken Brown 2017-10-23 11:38 ` Jon Turney 0 siblings, 1 reply; 8+ messages in thread From: Ken Brown @ 2017-10-21 20:19 UTC (permalink / raw) To: cygwin-apps [-- Attachment #1: Type: text/plain, Size: 666 bytes --] On 10/20/2017 6:24 PM, Ken Brown wrote: > Jon, > > 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 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. Ken [-- Attachment #2: 0001-Fix-parsing-of-setup.ini.patch --] [-- Type: text/plain, Size: 1369 bytes --] From af9829d2ee35686cf0f6e82c8fb04265b1f50f82 Mon Sep 17 00:00:00 2001 From: Ken Brown <kbrown@cornell.edu> Date: Sat, 21 Oct 2017 12:49:34 -0400 Subject: [PATCH] Fix parsing of setup.ini Reset "obsoletes" between packages. Also add a debugging statement. --- IniDBBuilderPackage.cc | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/IniDBBuilderPackage.cc b/IniDBBuilderPackage.cc index 3bc7b86..4e41659 100644 --- a/IniDBBuilderPackage.cc +++ b/IniDBBuilderPackage.cc @@ -85,6 +85,7 @@ IniDBBuilderPackage::buildPackage (const std::string& _name) cbpv.spkg = PackageSpecification(); cbpv.spkg_id = packageversion(); cbpv.requires = NULL; + cbpv.obsoletes = NULL; cbpv.archive = packagesource(); currentSpec = NULL; @@ -157,6 +158,7 @@ IniDBBuilderPackage::buildPackageSource (const std::string& path, SolverPool::addPackageData cspv = cbpv; cspv.type = package_source; cspv.requires = NULL; + cspv.obsoletes = NULL; /* set archive path, size, mirror, hash */ cspv.archive = packagesource(); @@ -229,6 +231,9 @@ IniDBBuilderPackage::buildBeginBuildDepends () void IniDBBuilderPackage::buildBeginObsoletes () { +#if DEBUG + Log (LOG_BABBLE) << "Beginning of an obsoletes statement" << endLog; +#endif currentSpec = NULL; obsoletesNodeList = PackageDepends(); currentNodeList = &obsoletesNodeList; -- 2.14.2 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [setup topic/libsolv] Does "obsoletes:" work? 2017-10-21 20:19 ` Ken Brown @ 2017-10-23 11:38 ` Jon Turney 2017-10-23 17:44 ` Ken Brown 0 siblings, 1 reply; 8+ messages in thread From: Jon Turney @ 2017-10-23 11:38 UTC (permalink / raw) To: cygwin-apps 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? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [setup topic/libsolv] Does "obsoletes:" work? 2017-10-23 11:38 ` Jon Turney @ 2017-10-23 17:44 ` Ken Brown 2017-10-24 20:09 ` Jon Turney 0 siblings, 1 reply; 8+ messages in thread From: Ken Brown @ 2017-10-23 17:44 UTC (permalink / raw) To: cygwin-apps 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. 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. Ken ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [setup topic/libsolv] Does "obsoletes:" work? 2017-10-23 17:44 ` Ken Brown @ 2017-10-24 20:09 ` Jon Turney 2017-10-24 20:25 ` Ken Brown 0 siblings, 1 reply; 8+ messages in thread From: Jon Turney @ 2017-10-24 20:09 UTC (permalink / raw) To: cygwin-apps 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [setup topic/libsolv] Does "obsoletes:" work? 2017-10-24 20:09 ` Jon Turney @ 2017-10-24 20:25 ` Ken Brown 2017-10-24 20:37 ` Jon Turney 0 siblings, 1 reply; 8+ messages in thread From: Ken Brown @ 2017-10-24 20:25 UTC (permalink / raw) To: cygwin-apps On 10/24/2017 4:09 PM, Jon Turney wrote: > 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. OK, so maybe there's no real problem here. In any case, the situation is unlikely to happen often -- the user has to intentionally choose to install an obsolete package. I think we might have reached the point where more widespread testing would be useful. If it would help, I could put together a patch series containing the various (sometimes revised) patches we've discussed recently. Ken ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [setup topic/libsolv] Does "obsoletes:" work? 2017-10-24 20:25 ` Ken Brown @ 2017-10-24 20:37 ` Jon Turney 2017-10-24 21:33 ` Ken Brown 0 siblings, 1 reply; 8+ messages in thread From: Jon Turney @ 2017-10-24 20:37 UTC (permalink / raw) To: cygwin-apps On 24/10/2017 21:24, Ken Brown wrote: > On 10/24/2017 4:09 PM, Jon Turney wrote: >> 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. > > OK, so maybe there's no real problem here. In any case, the situation > is unlikely to happen often -- the user has to intentionally choose to > install an obsolete package. I was wondering if there might be some scenario where A is in the base category, and obsoleted by B, where we'd really want to install B the first time on fresh installs, but, yeah, something we'd want to avoid in general... > I think we might have reached the point where more widespread testing > would be useful. If it would help, I could put together a patch series > containing the various (sometimes revised) patches we've discussed > recently. Cool, I was going to ask you how far along you were in your test plan :) I think I've been keeping track of your patches, so I've updated topic/libsolv with your patches and rebased onto master. If that looks good to you, I'll do test release. (I squashed "Fix parsing setup.ini" (for obsoletes) into "Add obsoletes: support", and added a missing break; in "Don't override a Skip selection") ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [setup topic/libsolv] Does "obsoletes:" work? 2017-10-24 20:37 ` Jon Turney @ 2017-10-24 21:33 ` Ken Brown 0 siblings, 0 replies; 8+ messages in thread From: Ken Brown @ 2017-10-24 21:33 UTC (permalink / raw) To: cygwin-apps On 10/24/2017 4:37 PM, Jon Turney wrote: > On 24/10/2017 21:24, Ken Brown wrote: >> On 10/24/2017 4:09 PM, Jon Turney wrote: >>> 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. >> >> OK, so maybe there's no real problem here. In any case, the situation >> is unlikely to happen often -- the user has to intentionally choose to >> install an obsolete package. > > I was wondering if there might be some scenario where A is in the base > category, and obsoleted by B, where we'd really want to install B the > first time on fresh installs, but, yeah, something we'd want to avoid in > general... > >> I think we might have reached the point where more widespread testing >> would be useful. If it would help, I could put together a patch >> series containing the various (sometimes revised) patches we've >> discussed recently. > Cool, I was going to ask you how far along you were in your test plan :) > > I think I've been keeping track of your patches, so I've updated > topic/libsolv with your patches and rebased onto master. If that looks > good to you, I'll do test release. > > (I squashed "Fix parsing setup.ini" (for obsoletes) into "Add obsoletes: > support", and added a missing break; in "Don't override a Skip selection") Looks good to me. The only issue I can think of that hasn't yet been fully addressed is the one I mentioned here: https://sourceware.org/ml/cygwin-apps/2017-10/msg00094.html . But I admit that this is an obscure corner case, and the patch I proposed at the beginning of that thread is probably not the best way to deal with it. So we might want to just leave it for now. Ken ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-10-24 21:33 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-10-20 22:25 [setup topic/libsolv] Does "obsoletes:" work? Ken Brown 2017-10-21 20:19 ` Ken Brown 2017-10-23 11:38 ` Jon Turney 2017-10-23 17:44 ` Ken Brown 2017-10-24 20:09 ` Jon Turney 2017-10-24 20:25 ` Ken Brown 2017-10-24 20:37 ` Jon Turney 2017-10-24 21:33 ` Ken Brown
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).