Problem with packagesource::sites in setup

[Ken Brown]

On 3/16/2018 7:44 AM, Ken Brown wrote:
> 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.

A patchset is on its way.

Ken