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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 4F587158232 for ; Sun, 24 Nov 2024 22:47:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CEC93E08A6 for ; Sun, 24 Nov 2024 22:47:33 +0000 (UTC) Received: from out2.migadu.com (out2.migadu.com [188.165.223.204]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 85403E0D2E for ; Wed, 6 Jul 2022 09:08:54 +0000 (UTC) Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=r0bert.dev; s=key1; t=1657098532; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/Y+yfU6v88HWR7oVPDtzSK8ADBL55+HnRuarN0KPhE8=; b=lu4T3ICbz4YAPbvB90/K08HAYH65cNBhyeFUNYhnBjB9luh4RfX8znxbVChvym6AcUpeKa vX+YFqMWYY2yaBeSKFY6Q05nicqVOMgGwbvR+bRzVTBp9kZ7xqpH2smeq+aCEgNleEPzk2 SHdGB6099Nl7nqfXDsrIIXpSmy6FEJ3PcTwqGM6st7BWSCGoCwitQshmVw9zqDDAZeOCr+ xZwJ4MsR6amLeUKt0doHKB2yXWBTMPh6C1OiGe1eIc3U7k2XXPreXTEGOFxfllyQiLSHWI aHXCDxXy2cUH9Uvfuqp27v4jHWJ232xRUndhsOl6Ej+/j6iyj/39VsoM7cVw8A== Subject: Re: [gentoo-guru] [RFC PATCH 0/3] eclass/R-packages: improvements X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Robert Greener To: Alessandro Barbieri Cc: gentoo-guru@lists.gentoo.org, Anna =?UTF-8?Q?=E2=80=9CCyberTailor=E2=80=9D?= Date: Wed, 06 Jul 2022 10:08:44 +0100 In-Reply-To: References: <010b0181cd374297-547f5cd8-3342-4193-970c-422efcd8fa0b-000000@eu-west-2.amazonses.com> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-ycpWt8WM2oEtTreXQTk8" Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Discussion on the GURU project and repository X-BeenThere: gentoo-guru@gentoo.org X-BeenThere: gentoo-guru@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: r0bert.dev X-Archives-Salt: bdfef80d-7803-485c-b019-d9582f9e471a X-Archives-Hash: 5cc0c7a7c4bc3be487298f779fe6f745 --=-ycpWt8WM2oEtTreXQTk8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2022-07-06 at 02:24 +0200, Alessandro Barbieri wrote: > Il giorno mar 5 lug 2022 alle ore 09:16 Robert Greener > ha > scritto: > > To fix this, I propose to change SRC_URI to use either src/contrib > > or > > src/contrib/Archive (where old packages will be). However, the > > drawback > > of this is that we only use the main CRAN. As there are many > > mirrors to > > search, it would be impractial to search them all before searching > > the > > archive. > > I think all the changes are fine. >=20 > The devmanual say: >=20 > There are two valid cases for using thirdpartymirrors: >=20 > =C2=A0=C2=A0 1. providing multiple download locations for mirror- or fetc= h- > restricted > =C2=A0=C2=A0 packages, > =C2=A0=C2=A0 2. dealing with upstreams that distribute their distfiles vi= a a > network > =C2=A0=C2=A0 of mirrors without a primary download location or a bouncer > service. >=20 > In any other case, the primary location must be used instead. The > distfiles > will be mirrored onto Gentoo infrastructure > ; > in that > case, the benefit to using third-party mirror list does not outweigh > the > burden of maintaining it. >=20 >=20 > So I think in this case we can drop the mirror list and go with the > hack of > listing both live and archive Anna (CyberTailor) (cc'd), made the point off list, that the multiple SRC_URIs as a backup is undefined in PMS, so it can't be relied on. We could get the sources directly in src_unpack (it may be better refactored into its own function, but just left as is for now). See the patch at the end. However, I don't really like this, as it makes the ebuild live, but it's not really a live ebuild. Also we lose the manifest... The other option would be to require an UPDATE_DATE variable to be set in the ebuilds, this could then be used like so:=C2=A0 SRC_URI=3D"https://cran.microsoft.com/snapshot/${UPDATE_DATE}/src/contrib/$= {PN}_${PV}.tar.gz" Where UPDATE_DATE=3DYYYY-MM-DD. This is a service provided by Microsoft that snapshots CRAN everyday at midnight UTC. This link will always resolve. I think this might the easiest solution, though would require updating the ebuilds in dev-R/*. What do you think? diff --git a/eclass/R-packages.eclass b/eclass/R-packages.eclass index aed8cce84..8a464c325 100644 --- a/eclass/R-packages.eclass +++ b/eclass/R-packages.eclass @@ -21,14 +21,14 @@ esac =20 EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_inst= all pkg_postinst =20 -SRC_URI=3D"mirror://cran/src/contrib/${PN}_${PV}.tar.gz" HOMEPAGE=3D"https://cran.r-project.org/package=3D${PN}" =20 SLOT=3D"0" =20 DEPEND=3D"dev-lang/R" RDEPEND=3D"${DEPEND}" -BDEPEND=3D"sys-apps/pkgcore" +BDEPEND=3D"sys-apps/pkgcore net-misc/wget" +PROPERTIES=3D"live" =20 # @FUNCTION: _movelink # @INTERNAL @@ -45,9 +45,16 @@ _movelink() { =20 # @FUNCTION: R-packages_src_unpack # @DESCRIPTION: -# function to unpack R packages into the right folder +# function to download and unpack R packages into the right folder R-packages_src_unpack() { - unpack ${A} + einfo "Trying live CRAN" + wget "https://cran.r-project.org/src/contrib/${PN}_${PV}.tar.gz" ||= { + einfo "Trying CRAN Archive" + wget "https://cran.r-project.org/src/contrib/Archive/${PN}/= ${PN}_${PV}.tar.gz" || die + } + + unpack "${WORKDIR}/${PN}_${PV}.tar.gz" + if [[ -d "${PN//_/.}" ]] && [[ ! -d "${P}" ]]; then mv "${PN//_/.}" "${P}" || die fi --=20 2.35.1 -- Robert --=-ycpWt8WM2oEtTreXQTk8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iIQEABYKACwWIQQqCMuNm+NLRc5qbt3NxclDHq2tqgUCYsVRHA4cbWVAcjBiZXJ0 LmRldgAKCRDNxclDHq2tqkh/AQDmWrEfZsM2/P0szwmxTwWPc5PqASCC6H5L7JdN snKNvwD+IFUVLQH1HHtJ0KrwkPlGSgH2tlq9w3q8D/VCKgoOmQY= =8LOI -----END PGP SIGNATURE----- --=-ycpWt8WM2oEtTreXQTk8--