From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19317 invoked by alias); 19 Oct 2017 17:14:27 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 19307 invoked by uid 89); 19 Oct 2017 17:14:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2164, adaptation, transfer, Hx-spam-relays-external:ESMTPA X-HELO: vsmx012.vodafonemail.xion.oxcs.net Received: from vsmx012.vodafonemail.xion.oxcs.net (HELO vsmx012.vodafonemail.xion.oxcs.net) (153.92.174.90) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Oct 2017 17:14:24 +0000 Received: from vsmx004.vodafonemail.xion.oxcs.net (unknown [192.168.75.198]) by mta-8-out.mta.xion.oxcs.net (Postfix) with ESMTP id 0680D8D338B for ; Thu, 19 Oct 2017 17:14:19 +0000 (UTC) Received: from Gertrud (unknown [91.47.62.96]) by mta-8-out.mta.xion.oxcs.net (Postfix) with ESMTPA id CD582CDFAE for ; Thu, 19 Oct 2017 17:14:16 +0000 (UTC) From: Achim Gratz To: cygwin-apps@cygwin.com Subject: Re: [setup topic/libsolv] Packages contained in multiple repositories References: <9db21b28-18fa-603d-dec2-e49f72f9832e@cornell.edu> <87k1zs4dej.fsf@Rainer.invalid> <16655ef1-6672-b071-29d2-e195c8411ba7@dronecode.org.uk> Date: Thu, 19 Oct 2017 17:14:00 -0000 In-Reply-To: <16655ef1-6672-b071-29d2-e195c8411ba7@dronecode.org.uk> (Jon Turney's message of "Thu, 19 Oct 2017 14:36:29 +0100") Message-ID: <87d15jnjq7.fsf@Rainer.invalid> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-VADE-STATUS: LEGIT X-SW-Source: 2017-10/txt/msg00088.txt.bz2 Jon Turney writes: >> Extrapolating from my experience with zypper, libsolv should stick with >> the repo the installed package comes from even if some other repo has a >> newer version. > > Unfortunately, we are limited by the fact that installed.db doesn't > record which repo an installed package came from. Which is something we might eventually change, but yes, we can't use that information at the moment if we can't figure out the sourtce repo by looking at the version. > We map repo setup.ini release: labels to package vendor names, so we > assume it's 'Cygwin' for an installed package (package_db.cc:115), and > run the solver with SOLVER_FLAG_ALLOW_VENDORCHANGE on (libsolv.cc:745) > to allow it to get upgraded by a package in the repo it actually came > from, but we've forgotten. Well actually zypper does the same thing if you have a package installed, but it's gone from the repos (we'd call that an orphan package): it'll show up as "@System" instead of the repo it came from originally. > I'm not overly concerned about this: we don't define what happens in > this situation currently, and if the packages are identical, it's no > problem. As long as the repos we're installing from use coordinated version/release numbers, then we could map them correctly as long as the packages are not orphaned. That would also allow to correctly "transfer" a package from a hypothetical "test" repo into the "current" repo, regardless of when it was originally installed. > If the packages are the same version but have different contents, > you're asking for problems, although I guess it would be nice to do > something defined in that situation. I think that the multiple repositories situation for zypper is still expected to provide either different versions or the same content. At least all the repositories that I'm aware of (that are supposed to work together) keep things that way. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada