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 944471396D9 for ; Sat, 21 Oct 2017 02:57:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B2CB12BC0A1; Sat, 21 Oct 2017 02:57:25 +0000 (UTC) Received: from blaine.gmane.org (unknown [195.159.176.226]) (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 4EF662BC087 for ; Sat, 21 Oct 2017 02:57:25 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1e5jy8-0001mG-8q for gentoo-dev@lists.gentoo.org; Sat, 21 Oct 2017 04:57:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Manifest2 hashes, take n+1-th Date: Sat, 21 Oct 2017 02:56:42 +0000 (UTC) Message-ID: References: <1508440120.19870.14.camel@gentoo.org> <20171020003258.7ad4695b@pc1> <1508542795.6784.4.camel@gentoo.org> 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-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@blaine.gmane.org User-Agent: Pan/0.143 (Quaint little villages here and there; 02834e6bc) X-Archives-Salt: 75ba0429-7c79-419c-99b9-58364d5bb693 X-Archives-Hash: 3d4015ebba2c1fe3e6e0901b00d58b3d Michał Górny posted on Sat, 21 Oct 2017 01:39:55 +0200 as excerpted: > W dniu pią, 20.10.2017 o godzinie 18∶42 -0400, użytkownik Anton Molyboha > napisał: >> Would it make sense then to support several hashes but let the user >> optionally turn off the verification of some of them, depending on the >> user's security vs performance requirements? >> > I won't block anyone from implementing such an option but I won't spend > my time on it either. However, if you believe verifying two checksums > could be a problem, then I have serious doubts if you hardware is > capable of building anything. When does this verification happen? If it's during --sync or --pretend/ask, as I believe it is based on when I get errors if I edit and forget to manifest/digest, then arguably time matters rather more than it does if it's only after the user has OKed the merge and it's doing the build. Because the time before the PM tells me what it's going to do and asks my OK before doing it is time I'm generally actually waiting for it (tho I'm normally doing something else while waiting, but I /am/ waiting) to decide whether I want to go ahead, or perhaps I need to change something first, while the actual build time after I've OKed it, doesn't matter so much, because I'm not actually waiting on it, I'm doing other things, which can actually include turning in for the night or going to work, with the intent being that it'll be done when I get back to it. So the hash verification time really does matter, even if it's minutes compared to hours of actual build time, because that's time I'm actively waiting for it, vs. letting it do its thing in the background, with much less concern about how long (within reason) it might take. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman