public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Achim Gratz <Stromeko@nexgo.de>
To: cygwin-apps@cygwin.com
Subject: Re: [setup topic/libsolv] Packages contained in multiple repositories
Date: Thu, 19 Oct 2017 17:14:00 -0000	[thread overview]
Message-ID: <87d15jnjq7.fsf@Rainer.invalid> (raw)
In-Reply-To: <16655ef1-6672-b071-29d2-e195c8411ba7@dronecode.org.uk> (Jon	Turney's message of "Thu, 19 Oct 2017 14:36:29 +0100")

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

  reply	other threads:[~2017-10-19 17:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-18 14:15 Ken Brown
2017-10-18 16:41 ` Achim Gratz
2017-10-19 13:36   ` Jon Turney
2017-10-19 17:14     ` Achim Gratz [this message]
2017-10-21 20:21     ` Ken Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d15jnjq7.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).