public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] New distfile mirror layout
Date: Tue, 29 Oct 2019 15:45:34 +0100	[thread overview]
Message-ID: <1e5681ee9c7efc9acadb9593b0a3645812b87651.camel@gentoo.org> (raw)
In-Reply-To: <20191029143304.GC22441@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 2879 bytes --]

On Tue, 2019-10-29 at 15:33 +0100, Fabian Groffen wrote:
> On 29-10-2019 15:17:38 +0100, Ulrich Mueller wrote:
> > > > > > > On Tue, 29 Oct 2019, Michał Górny wrote:
> > > On Tue, 2019-10-29 at 14:09 +0100, Ulrich Mueller wrote:
> > > > > What if the file is hosted at a non-standard tcp port upstream
> > > > > (like http://example.org:8080/)? The devmanual says that it _must_
> > > > > be manually uploaded to /space/distfiles-local/ in such cases.
> > > > Or another example, app-emacs/vhdl-mode-3.38.1, where (incompetent,
> > > > or nasty?) upstream blocks wget for some reason, but other methods
> > > > (e.g., curl, firefox) work? How would I get the file onto the mirrors
> > > > there?
> > > If I were you, I would've explicitly mirrored the file anyway.
> > > If upstream blocks wget, then users who do not use GENTOO_MIRRORS will
> > > also suffer due to it.
> > 
> > All what I'm saying is that there can be unusual circumstances where
> > manual uploading of a file is useful. So please don't take that
> > possibility away.
> 
> In addition, there are currently files there that aren't referenced from
> ebuilds.  Prefix uses these files during bootstrap, local mirrors are
> often much faster than dev.g.o.
> 
> If the files don't get mirrored anymore, I guess I can create a dummy
> ebuild that has the files in SRC_URI.

Ok, this is something I wasn't aware of.  I agree that dummy ebuild
should not be necessary here.  However, I'm also not sure if distfiles-
local is really the proper way either, especially that I don't see such
files on woodpecker right now.

I don't think the matter is urgent right now, so let's ponder on it
a bit.  In particular, I think we should have a clear indication of who
added which files, when, what for and where they came from.  Those are
precisely the things that the current distfiles-local approach misses.

> If the files get mirrored, but put in a subdir based on the filename
> hash, the original query endpoint on distfiles.g.o changes, much like
> the SRC_URI approach.
> 
> Now I can use distfiles.prefix.b.n which redirects to the distfiles.g.o
> URL with subdir for most part I think, but it's sub-optimal from my
> point of view.  Calculating the hash is not always feasible due to the
> lack of b2sum or other means.  Hence my earlier request to have such
> official translation service on Gentoo hardware.
> 
> (I just wrote a small wsgi script that calculates the hash and generates
> the redirect from Python, served via uwsgi/nginx, but there should be
> many ways to achieve the same goals, if and only if a blake2b
> implementation were available for it.)
> 

This is also something that needs thinking.  I personally don't mind
having one but it would be nice if it was able to account for geodns
and such.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

  reply	other threads:[~2019-10-29 14:45 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-18 13:41 [gentoo-dev] New distfile mirror layout Michał Górny
2019-10-18 19:53 ` Richard Yao
2019-10-18 20:49   ` Michał Górny
2019-10-19  1:09     ` Richard Yao
2019-10-19  6:17       ` Michał Górny
2019-10-19  8:20         ` Richard Yao
2019-10-19 19:26       ` Richard Yao
2019-10-19 20:02         ` Michał Górny
2019-10-19 22:48           ` Richard Yao
2019-10-22  0:46   ` James Cloos
2019-10-19 13:31 ` Fabian Groffen
2019-10-19 13:53   ` Michał Górny
2019-10-19 23:24 ` Joshua Kinard
2019-10-19 23:57   ` Alec Warner
2019-10-20  0:14     ` Joshua Kinard
2019-10-20  6:51   ` Michał Górny
2019-10-20  8:25     ` Joshua Kinard
2019-10-20  8:32       ` Michał Górny
2019-10-20  9:21         ` Joshua Kinard
2019-10-20  9:44           ` Michał Górny
2019-10-20 20:57             ` Joshua Kinard
2019-10-21  0:05               ` Joshua Kinard
2019-10-21  5:51                 ` Ulrich Mueller
2019-10-21 10:17                 ` Kent Fredric
2019-10-21 21:34                 ` Mikle Kolyada
2019-10-21 10:13               ` Kent Fredric
2019-10-23  5:16                 ` Joshua Kinard
2019-10-29 16:35                   ` Kent Fredric
2019-10-20 17:09       ` Matt Turner
2019-10-21 16:42     ` Richard Yao
2019-10-21 23:36       ` Matt Turner
2019-10-23  5:18         ` Joshua Kinard
2019-10-23 17:06           ` William Hubbs
2019-10-23 18:38             ` William Hubbs
2019-10-23 22:04           ` William Hubbs
2019-10-24  4:30             ` Michał Górny
2019-10-22  6:51       ` Jaco Kroon
2019-10-22  8:43         ` Ulrich Mueller
2019-10-22  8:46           ` Jaco Kroon
2019-10-23 23:47         ` ext4 readdir performance - was " Richard Yao
2019-10-24  0:01           ` Richard Yao
2019-10-23  1:21       ` Rich Freeman
2019-10-28 23:24     ` Chí-Thanh Christopher Nguyễn
2019-10-29  4:27       ` Michał Górny
2019-10-29  9:34         ` Fabian Groffen
2019-10-29 11:11           ` Michał Górny
2019-10-29 12:23             ` Ulrich Mueller
2019-10-29 12:43               ` Michał Górny
2019-10-29 13:03                 ` Ulrich Mueller
2019-10-29 13:09                   ` Ulrich Mueller
2019-10-29 13:52                     ` Michał Górny
2019-10-29 14:17                       ` Ulrich Mueller
2019-10-29 14:33                         ` Fabian Groffen
2019-10-29 14:45                           ` Michał Górny [this message]
2019-10-29 14:56                             ` Fabian Groffen
2019-10-29 13:51                   ` Michał Górny

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=1e5681ee9c7efc9acadb9593b0a3645812b87651.camel@gentoo.org \
    --to=mgorny@gentoo.org \
    --cc=gentoo-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