Problem with packagesource::sites in setup

[Ken Brown]

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.

Ken