From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-83638-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by finch.gentoo.org (Postfix) with ESMTPS id 0B2EB1382C5
for <garchives@archives.gentoo.org>; Sat, 27 Jan 2018 02:44:29 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 78EE7E0984;
Sat, 27 Jan 2018 02:44:21 +0000 (UTC)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 0936CE0863
for <gentoo-dev@lists.gentoo.org>; Sat, 27 Jan 2018 02:44:20 +0000 (UTC)
Received: by mail-lf0-x22b.google.com with SMTP id g72so2951565lfg.5
for <gentoo-dev@lists.gentoo.org>; Fri, 26 Jan 2018 18:44:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:content-transfer-encoding;
bh=F7RTGMplBWQO05izu/5IMcJfRnpFfX/qzHcz7cT4RJQ=;
b=VUdG826rQbTrc0jBrzLWhJJDiB4miPRQnR2qX5rVaDp0NJdl/yXK4hgsMDFR74YM1O
TAHzLR6sUHe4wchgrTcyZtSFV+5aS3ZOLne46jsYozMiH4cVW+X94sLh+ztFaqer7bXF
b3fH+tXOWZyLpUiNm+NzGfQ5OcCwVysFewfo7JXrA4zvUpmZsAUEQxiCmDu14wUl1ODH
AfbuL5oDM+ZKOBEsjvW+FtYfW2Hx6+hKTtkK+ph6q9CDYVZmKLXR++xwSMSuB9GVKzgt
dL+sSJJdC126Bbyqzt+B/zS54p0g6YWE/ghPo9YaGsHKRLIvATClmz30gRAg0ekrtRca
qNjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:content-transfer-encoding;
bh=F7RTGMplBWQO05izu/5IMcJfRnpFfX/qzHcz7cT4RJQ=;
b=pIgRC5YoZpmqHZ2PgMo8dq4PTT116Xglt880HIyZYEJZUpsK75pyc90QK4ypu4/N2P
pI26pNPMa/Uq6Od5zoEbl8tM1eX9jLmNzUc7KkYO2nsKrFI2/iylgvs2hrt+hyuB/mbd
HBGljpUtDhp6aooxXS5QCNc9EozeGipnhuAe53AMCUXPqwLtJSpnJ0dt5sKS3J5h/kWw
g79L75hjknXYnRRPKk1CXXccbQeQeia50RNn3eRs+weSu4jZaPPiMWVxuJ6fhmFV7JGG
FWPWLGOQqA0bdbYmaHEC/RDgq2bxNOGsf31mSGro6c8NbYlJMcIvQmtklY4hSeDpgfzu
FNRw==
X-Gm-Message-State: AKwxytf7yV6WJRmmxa2JddXuiD5mBuy+okiKVl+gNm73ovgNdZHUO+qO
MNfe+F/ABEHNVtY1s6pOZp43s/i8WsfkcTJDfvQ=
X-Google-Smtp-Source: AH8x227M0R8W2pR381IUUWj6exd9Jr/8k2d3lKOQHiotYniVGcElhZei2FeO8Q8zwCMkBxm3HXwDD00cZn+bZNneJfg=
X-Received: by 10.46.115.22 with SMTP id o22mr9869705ljc.89.1517021058134;
Fri, 26 Jan 2018 18:44:18 -0800 (PST)
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.46.93.70 with HTTP; Fri, 26 Jan 2018 18:44:17 -0800 (PST)
In-Reply-To: <fa5aeedd-7a53-c2e7-d163-c16482028b11@gentoo.org>
References: <1517009079.31015.3.camel@gentoo.org> <fa5aeedd-7a53-c2e7-d163-c16482028b11@gentoo.org>
From: R0b0t1 <r030t1@gmail.com>
Date: Fri, 26 Jan 2018 20:44:17 -0600
Message-ID: <CAAD4mYj1fivv4KOaHHHg6tqFne6MFRDDRvSkQXddHUHas_DzOQ@mail.gmail.com>
Subject: Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure
To: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 22cd1967-5ec8-431e-9e3f-b700ab2e5101
X-Archives-Hash: 87b291a015746cc2123fafee288d4dde
On Fri, Jan 26, 2018 at 7:48 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> On 01/26/2018 06:24 PM, Micha=C5=82 G=C3=B3rny wrote:
>>
>> The alternate option of using file hash has the advantage of having
>> a more balanced split. Furthermore, since hashes are stored
>> in Manifests using them is zero-cost. However, this solution has two
>> significant disadvantages:
>>
>> 1. The hash values are unknown for newly-downloaded distfiles, so
>> ``repoman`` (or an equivalent tool) would have to use a temporary
>> directory before locating the file in appropriate subdirectory.
>>
>> 2. User-provided distfiles (e.g. for fetch-restricted packages) with
>> hash mismatches would be placed in the wrong subdirectory,
>> potentially causing confusing errors.
>>
>
> The filename proposal sounds fine,
I've had to interact with the distfile server by hand, and would
appreciate it if the files can be maintained in some way that finding
them is obvious without tools.
Every once and a while I navigate to the distfile root and need to
forcefully exit Firefox.
Cheers,
R0b0t1