From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 588D01382C5 for ; Sat, 27 Jan 2018 18:14:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2ABECE081A; Sat, 27 Jan 2018 18:14:19 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 D1B20E0A52 for ; Sat, 27 Jan 2018 18:14:18 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 07C31335C0C; Sat, 27 Jan 2018 18:14:16 +0000 (UTC) Message-ID: <1517076853.935.0.camel@gentoo.org> Subject: Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Sat, 27 Jan 2018 19:14:13 +0100 In-Reply-To: <87757435-488a-ae4c-abbf-b208cc314740@gentoo.org> References: <1517009079.31015.3.camel@gentoo.org> <1517041828.3816.3.camel@gentoo.org> <87757435-488a-ae4c-abbf-b208cc314740@gentoo.org> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: afd92abc-84ed-48e5-9be6-1f304d7a3733 X-Archives-Hash: 3de65566058c78d76e49bba150ef37b4 W dniu sob, 27.01.2018 o godzinie 11∶47 -0500, użytkownik Michael Orlitzky napisał: > On 01/27/2018 03:30 AM, Michał Górny wrote: > > > > > > What are we worried about in using a temporary directory? Copying across > > > filesystem boundaries? Except in rare cases, $DISTDIR itself will be > > > usable a temporary location (on the same filesystem), won't it? > > > > Why add the extra complexity when there's no need for one? Note that > > there's also the problem of resuming transfers, so in the end we're > > talking about permanent temporary directory where we keep unfinished > > transfers. > > Can't argue with that, but I don't see it as a huge "con." > > > > > For the second point, portage is going to tell me where to put the file, > > > isn't it? Then no matter what garbage I download, won't portage look for > > > it in the right place, because where-to-put-it is determined using the > > > same manifest hash that determines where-to-find-it? > > > > No, it won't. Why would it? You're going to call something like: > > > > edistadd foo.tar.gz bar.tar.gz > > > > ...and it will place the files in the right subdirectories. > > If we have a tool like edistadd, then I see the problem. But if we were > going to use file-data based hashes, then there would be no need for a > tool in most cases. As a developer, "repoman manifest" would handle it. > As a user, I'm going to see a message like, > > Fetch instructions for games-fps/doom3-lms-4: > * Please download LastManStandingCoop4Multiplatform.zip from: > * http://www.moddb.com/mods/last-man-standing-coop/downloads > * and move it to /var/cache/portage/distfiles > > except instead of $DISTDIR, it would suggest whatever directory is > computed from the hash in the manifest. > How would that work if you had 5 different files, every one evaluating to a different directory? -- Best regards, Michał Górny