Problem with packagesource::sites in setup
Fri Mar 16 11:45:00 GMT 2018
On 3/15/2018 10:42 PM, Ken Brown wrote:
> On 3/15/2018 6:07 PM, Jon Turney wrote:
>> 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.
> I hadn't thought of that.Â But will one really overwrite the other or
> will we just get several copies of the same package and version in the
> "cygwin" repo, each with its own site?
>> Â 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)
> No, but it can help if one mirror is having transient network problems.
> For example, we might get a corrupt archive from one mirror, and then
> the loop in download.cc:download_one() will try the next one.Â I have no
> idea how many users use more than one mirror with the expectation that
> this will happen.Â Probably not many.
>> But, yeah, what we are doing currently is probably wrong.
> And I'm less convinced now that it's worth worrying about.
I just realized that this affects local installs also. Here it's not
unusual for a user to have several mirror directories from different
setup runs. But if two different setup.ini files list a given
packageversion, setup will offer it for install only if the archive is
found in the directory corresponding to the last setup.ini read.
So I do think this should be fixed.
More information about the Cygwin-apps