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 172AE1382C5 for ; Wed, 7 Feb 2018 07:34:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6F56AE095E; Wed, 7 Feb 2018 07:34:25 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [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 0AF1CE0848 for ; Wed, 7 Feb 2018 07:34:23 +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 E9E3C335C0C; Wed, 7 Feb 2018 07:34:21 +0000 (UTC) Message-ID: <1517988858.1228.1.camel@gentoo.org> Subject: Re: [gentoo-dev] [PATCH] bzr.eclass: Drop bzr_bootstrap and bzr_src_prepare. From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Wed, 07 Feb 2018 08:34:18 +0100 In-Reply-To: <23162.14634.675867.438221@a1i15.kph.uni-mainz.de> References: <23161.46157.292874.951208@a1i15.kph.uni-mainz.de> <23162.14634.675867.438221@a1i15.kph.uni-mainz.de> 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: 3e91936c-2d0f-49c6-95cb-497a5962484d X-Archives-Hash: d394674b7b39c8789090dfd330909c02 W dniu śro, 07.02.2018 o godzinie 00∶24 +0100, użytkownik Ulrich Müller napisał: > No ebuild in the Gentoo repository uses the bzr_bootstrap > functionality. Therefore drop the function along with bzr_src_prepare > (which would not have worked in EAPI 6 anyway, due to missing call to > eapply_user). After this change, inheriting eutils is not needed any > more. > > Drop support for EAPIs 0 and 1 for further simplification. > --- > > This is to be applied on top of the patch posted earlier today. > > We could go for bzr-r1.eclass instead. However, the functionality > associated with EBZR_PATCHES and EBZR_BOOTSTRAP is not used in the > tree, and overall the eclass is little used. Therefore I think that > applying these changes in-place is acceptable here. > > eclass/bzr.eclass | 99 ++++++++----------------------------------------------- > 1 file changed, 13 insertions(+), 86 deletions(-) > > diff --git a/eclass/bzr.eclass b/eclass/bzr.eclass > index 9b3e0b6cf4dc..710b64db28c0 100644 > --- a/eclass/bzr.eclass > +++ b/eclass/bzr.eclass > @@ -18,21 +18,20 @@ > # Note: Just set EBZR_REPO_URI to the URI of the branch and src_unpack() > # of this eclass will export the branch to ${WORKDIR}/${P}. > > -inherit eutils > - > EBZR="bzr.eclass" > > -case "${EAPI:-0}" in > - 0|1) EXPORT_FUNCTIONS src_unpack ;; > - *) EXPORT_FUNCTIONS src_unpack src_prepare ;; > +case ${EAPI:-0} in > + 2|3|4|5|6) ;; > + *) die "${EBZR}: EAPI ${EAPI:-0} is not supported" ;; > esac > > -DEPEND=">=dev-vcs/bzr-2.6.0" > -case "${EAPI:-0}" in > - 0|1) ;; > - *) [[ ${EBZR_REPO_URI%%:*} = sftp ]] \ > - && DEPEND=">=dev-vcs/bzr-2.6.0[sftp]" ;; > -esac > +EXPORT_FUNCTIONS src_unpack > + > +if [[ ${EBZR_REPO_URI%%:*} = sftp ]]; then > + DEPEND=">=dev-vcs/bzr-2.6.0[sftp]" > +else > + DEPEND=">=dev-vcs/bzr-2.6.0" > +fi > > # @ECLASS-VARIABLE: EBZR_STORE_DIR > # @DESCRIPTION: > @@ -85,9 +84,8 @@ esac > # @DESCRIPTION: > # The repository URI for the source package. > # > -# Note: If the ebuild uses an sftp:// URI, then in EAPI 0 or 1 it must > -# make sure that dev-vcs/bzr was built with USE="sftp". In EAPI 2 or > -# later, the eclass will depend on dev-vcs/bzr[sftp]. > +# Note: If the ebuild uses an sftp:// URI, then the eclass will depend > +# on dev-vcs/bzr[sftp]. > > # @ECLASS-VARIABLE: EBZR_INITIAL_URI > # @DEFAULT_UNSET > @@ -100,21 +98,6 @@ esac > # > # Normally, this variable needs not be set. > > -# @ECLASS-VARIABLE: EBZR_BOOTSTRAP > -# @DEFAULT_UNSET > -# @DESCRIPTION: > -# Bootstrap script or command like autogen.sh or etc. > - > -# @ECLASS-VARIABLE: EBZR_PATCHES > -# @DEFAULT_UNSET > -# @DESCRIPTION: > -# bzr.eclass can apply patches in bzr_bootstrap(). You can use regular > -# expressions in this variable like *.diff or *.patch and the like. > -# Note: These patches will be applied before EBZR_BOOTSTRAP is processed. > -# > -# Patches are searched both in ${PWD} and ${FILESDIR}. If not found in > -# either location, the installation dies. > - > # @ECLASS-VARIABLE: EBZR_PROJECT > # @DESCRIPTION: > # The project name of your ebuild. Normally, the branch will be stored > @@ -276,65 +259,9 @@ bzr_fetch() { > popd > /dev/null > } > > -# @FUNCTION: bzr_bootstrap > -# @DESCRIPTION: > -# Apply patches in ${EBZR_PATCHES} and run ${EBZR_BOOTSTRAP} if specified. > -bzr_bootstrap() { > - local patch lpatch > - > - pushd "${S}" > /dev/null || die "${EBZR}: can't chdir to ${S}" > - > - if [[ -n ${EBZR_PATCHES} ]] ; then > - einfo "apply patches -->" > - > - for patch in ${EBZR_PATCHES} ; do > - if [[ -f ${patch} ]] ; then > - epatch "${patch}" > - else > - # This loop takes care of wildcarded patches given via > - # EBZR_PATCHES in an ebuild > - for lpatch in "${FILESDIR}"/${patch} ; do > - if [[ -f ${lpatch} ]] ; then > - epatch "${lpatch}" > - else > - die "${EBZR}: ${patch} is not found" > - fi > - done > - fi > - done > - fi > - > - if [[ -n ${EBZR_BOOTSTRAP} ]] ; then > - einfo "begin bootstrap -->" > - > - if [[ -f ${EBZR_BOOTSTRAP} ]] && [[ -x ${EBZR_BOOTSTRAP} ]] ; then > - einfo " bootstrap with a file: ${EBZR_BOOTSTRAP}" > - "./${EBZR_BOOTSTRAP}" \ > - || die "${EBZR}: can't execute EBZR_BOOTSTRAP" > - else > - einfo " bootstrap with commands: ${EBZR_BOOTSTRAP}" > - "${EBZR_BOOTSTRAP}" \ > - || die "${EBZR}: can't eval EBZR_BOOTSTRAP" > - fi > - fi > - > - popd > /dev/null > -} > - > # @FUNCTION: bzr_src_unpack > # @DESCRIPTION: > -# Default src_unpack(), calls bzr_fetch. For EAPIs 0 and 1, also calls > -# bzr_src_prepare. > +# Default src_unpack(), calls bzr_fetch. > bzr_src_unpack() { > bzr_fetch > - case "${EAPI:-0}" in > - 0|1) bzr_src_prepare ;; > - esac > -} > - > -# @FUNCTION: bzr_src_prepare > -# @DESCRIPTION: > -# Default src_prepare(), calls bzr_bootstrap. > -bzr_src_prepare() { > - bzr_bootstrap > } Hmm, unless I'm mistaken, this can cause another definition of src_prepare to start applying to ebuilds. You can submit a PR with this change to get md5-cache with exported phase data suitable for comparison. Or... given the popularity of the eclass, you can check by hand ;-P. -- Best regards, Michał Górny