From: Scott Taylor <security@303underground.com>
To: gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] Feature request
Date: Thu, 01 Jan 2004 14:43:19 -0700 [thread overview]
Message-ID: <1072993399.11196.21.camel@Star.BerthoudWireless.net> (raw)
In-Reply-To: <200401012219.22851.pauldv@gentoo.org>
The default list of sourceforge (and other) mirrors would seem to me to
be well suited to being in make.globals where their value and syntax are
easily found, and new values can easily be placed in make.conf for those
who prefer other mirror sites. and bad mirrors can get yanked. Like for
example, every once in a while a gnukorea (or something like that) comes
up as an attempted mirror, however an emerge gets stuck there because
its asking for a password. If the lists of available mirrors were more
easily found and updated, it would be a lot easier to fix things like
that.
And I wouldn't expect it to be too difficult to add a
FEATURE="ignorenomirror". The machines inside my network only try my
local mirror, plus one of the gentoo mirrors before trying the
non-mirrored source uri anyway, so ignoring the nomirror directive is
not going to cause a drastic increase in file not found requests from
the mirrors. The server hosting the distfiles here would be left with a
normal set of source mirrors, and obeying the nomirror directive like
everyone else.
I might be the only one trying to do it just like this, but I'm
certainly not the only one trying to share out my own distfiles
directory on an internal network. I've even considered burning distfiles
snapshots on dvd-r to leave in otherwise unused drives. Also, I'd heard
a request from catalyst that portage be able to understand directory
paths as a mirror source. Thats another fine example of using a local
distfile store of some sort that you would much prefer to have it try
first, while ignoring a nomirror directive.
On Thu, 2004-01-01 at 14:19, Paul de Vrieze wrote:
> This does not mean that mirror selection can and should be done better,
> however it is hard to come up with a real good algorithm that does not
> involve people changing things by themselves (but still allows them to)
>
> Paul
--
Scott Taylor - <security@303underground.com>
The Golden Rule of Arts and Sciences:
He who has the gold makes the rules.
--
gentoo-portage-dev@gentoo.org mailing list
next prev parent reply other threads:[~2004-01-01 21:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1AbhRM-0007Ja-C9@smtp.gentoo.org>
2004-01-01 19:54 ` [gentoo-portage-dev] Feature request Paul de Vrieze
2004-01-01 20:14 ` Scott Taylor
2004-01-01 20:24 ` Paul de Vrieze
2004-01-01 20:43 ` Scott Taylor
2004-01-01 21:19 ` Paul de Vrieze
2004-01-01 21:43 ` Scott Taylor [this message]
2004-01-02 5:08 ` Brian
[not found] <E1AbhRH-0004kq-Lq@smtp.gentoo.org>
2004-01-02 20:20 ` Marius Mauch
2003-12-31 14:34 Allen Parker
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=1072993399.11196.21.camel@Star.BerthoudWireless.net \
--to=security@303underground.com \
--cc=gentoo-portage-dev@lists.gentoo.org \
/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