This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: Problem with packagesource::sites in setup
- From: Jon Turney <jon dot turney at dronecode dot org dot uk>
- To: "cygwin-apps at cygwin dot com" <cygwin-apps at cygwin dot com>
- Date: Thu, 15 Mar 2018 22:07:42 +0000
- Subject: Re: Problem with packagesource::sites in setup
- References: <524788d7-3a0d-dd1a-9c02-021ad1606361@cornell.edu>
On 15/03/2018 21:23, Ken Brown wrote:
I think we're currently mishandling packagesource::sites when several
libsolv repos contain the same version of a package. If I'm not
mistaken, we create a new packageversion pv for each repo, and
pv.source()->sites contains a single site, corresponding to that repo.
So we never take advantage of the fact that we have more than one mirror
(or mirror directory) from which we can potentially obtain an archive
for the package.
Hmm... I think this is going to interact with the package repositories
release: label. If they are both "cygwin", then one will overwrite the
other. If they are different, then we'll have 2 separate libsolv repos.
In the first case, I'm not sure that having the same package available
from more than one package repository mirror was ever was doing anything
terribly useful (i.e. it doesn't make the download any faster, or more
reliable)
But, yeah, what we are doing currently is probably wrong.
In the second case, it's possible for the length/hash of the "same"
version to be different, so it's not clear in what sense they really are
the same, and I think it's random which one we're going to get
(silently), which is unhelpful at best...
I think the way to fix this is to consolidate all the packageversions pv
into a single one, which knows about all the sites.
This could be handled by packagemeta::add_version(). When it replaces
an existing version, it could remove the old one from the pool after
copying the sites information. In order to obtain the sites
information, it would have to be able to query the libsolv pool, so we
would have to internalize repo data as we go along, presumably in the
IniDBBuilderPackage destructor.
Does this sound about right? If so, I'll try to prepare a patch. Or
maybe there's a better/easier way to solve the problem.