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 523F6138334 for ; Thu, 18 Oct 2018 13:35:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E959CE09D9; Thu, 18 Oct 2018 13:35:22 +0000 (UTC) Received: from smtp.gentoo.org (unknown [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 7D679E09D6 for ; Thu, 18 Oct 2018 13:35:22 +0000 (UTC) Received: from katipo2.lan (unknown [203.86.205.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: kentnl) by smtp.gentoo.org (Postfix) with ESMTPSA id D891C335CFE for ; Thu, 18 Oct 2018 13:34:58 +0000 (UTC) Date: Fri, 19 Oct 2018 02:34:22 +1300 From: Kent Fredric To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Can pkg_nofetch determine if a file is already downloaded? Message-ID: <20181019023422.2bad55a2@katipo2.lan> In-Reply-To: References: <1539626738.1014.0.camel@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) 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: multipart/signed; micalg=pgp-sha256; boundary="Sig_/._qOG31qUpT1BNH8Er1BfKK"; protocol="application/pgp-signature" X-Archives-Salt: daf5c335-cb7f-49c1-b09b-2a501a6aeaf5 X-Archives-Hash: 385b4ead24b2eca6695e0511464e6ab2 --Sig_/._qOG31qUpT1BNH8Er1BfKK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 17 Oct 2018 16:14:37 +0000 Micha=C5=82 G=C3=B3rny wrote: > Dnia October 17, 2018 4:03:17 PM UTC, Michael Haubenwallner napisa=C5=82(a): > >On 10/15/2018 08:05 PM, Micha=C5=82 G=C3=B3rny wrote: =20 > >> On Mon, 2018-10-15 at 13:34 +0200, Michael Haubenwallner wrote: =20 > >>> Hi, > >>> > >>> in pkg_nofetch, beyond to "direct the user to download relevant =20 > >source files", =20 > >>> I've found it useful to tell the user which filesystem directory to = =20 > >put the =20 > >>> files into once downloaded. > >>> > >>> Beyond that, I've also found it useful to tell the user whether a =20 > >relevant =20 > >>> source file is 'already there' or 'still missing'. > >>> > >>> Since the EAPI 6 related update to pkg_* phases to not have access =20 > >to DISTDIR =20 > >>> (even in earlier EAPI) any more, I'm wondering if both informations = =20 > >are still =20 > >>> available to pkg_nofetch in one or another way. > >>> > >>> Any idea? > >>> > >>> Or is my only option to reduce the information to "all these files =20 > >need to be =20 > >>> put in your DISTDIR", requiring the user to find out both the right = =20 > >DISTDIR =20 > >>> and which of the listed files are still missing herself? > >>> =20 > >>=20 > >> How would you know whether the file in DISTDIR is correct and =20 > >complete? =20 > >> =20 > >Well, pkg_nofetch is called only if some files are still missing, > >so portage really should have checked them before, and eventually > >renamed invalid files to "checksum_failure", no? =20 >=20 > Maybe. That's entirely undefined behavior. >=20 Does the construction of the shadow dir happen before checksum etc validation? Or does it happen afterwards? One option would potentially be to only create entries in the shadow dir if they're verified to be complete as per Manifest. Then a simple -e test is all that's needed to know if its downloaded yet. ( But PMS will need to stipulate which phases -e tests should be able to check this ) Outside that, perhaps a future EAPI could have a function for this purpose, where the function is defined to only return a true value if the distfile exists *and* is Manifestly correct ( doing on-demand verification and possibly caching it ) --Sig_/._qOG31qUpT1BNH8Er1BfKK Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEgdrME8Lrmai3DXYJda6SGagVg7UFAlvIi+4ACgkQda6SGagV g7VvVg//W8NtZqXXTXh/uMZnboSFCOweNfSpmN1v4QqoHvhuAPyYNF/Sht6cAilS HIf0Mv7ZudiRFrBp0mnJ1GyG8tYnm/fVcHuL+SztoBgCQi9QBPeRvB3JTUetU5Ei vgboieoDkxwrXX/f1iifOknxabAulirtpbqQ5f5juauG/JEaAeQXhuNfPCU5fwN+ u3ytiV1HAvdRDbnl2Ku/nN7Waq+yVQDrCtkTeSv39wNw+6lA0jmksMNlY4Pc5Unw tjCeB4UIXF3KYF3S9vwT0hnv1gVT8g8CRf2I1jt5LxUWVHlxXaPMqjY5+7RfyftD 91PPP9YH4JRjiGHbv9f4Lt+j86yMeNchYYNkr515X8KxbL2ry6CyILaA8avuDt9+ AJvCVFGiC6OMQ+BHEIjeY1OgOqU7//SLAQf2tXvWNuKu87AWfhtCsHOX4FMYYAwX xS+4CP+vBCwAkfH54BH9GgoNntSdZFGKp59LnzFJC5l0BUu5FN+c6k6OyHuE1Q6J Yt8rVZPaXcPiHqwky5X4DZ8DyZgS8pNii5v9sNhq6bZJizjfkU492HeBSY2x5yNR O4Qy3jMn8VxJ8ffO0ekZsueOmFHgKuP5M08mS0pbxTU9WionnbPj5x8SzzA/1ya9 m8zJ0qvKv8t+Pq/QQYcsbIMiGu9CK5E61PVUAphTXoCXrOwC6d4= =ojp1 -----END PGP SIGNATURE----- --Sig_/._qOG31qUpT1BNH8Er1BfKK--