From: Ken Brown <kbrown@cornell.edu>
To: cygwin-apps@cygwin.com
Subject: Re: Problem with packagesource::sites in setup
Date: Sat, 17 Mar 2018 14:59:00 -0000 [thread overview]
Message-ID: <4c55c77d-77b0-9ef2-b20e-ea0b7326e3bd@cornell.edu> (raw)
In-Reply-To: <871b2b53-f653-e463-1ddb-682fd8cb5102@cornell.edu>
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
next prev parent reply other threads:[~2018-03-17 14:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-15 21:23 Ken Brown
2018-03-15 22:07 ` Jon Turney
2018-03-16 2:42 ` Ken Brown
2018-03-16 11:45 ` Ken Brown
2018-03-17 14:59 ` Ken Brown [this message]
2018-03-16 19:36 ` Achim Gratz
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=4c55c77d-77b0-9ef2-b20e-ea0b7326e3bd@cornell.edu \
--to=kbrown@cornell.edu \
--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).