From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NuOmO-0002q9-Eg for garchives@archives.gentoo.org; Wed, 24 Mar 2010 11:29:44 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B3597E07FD; Wed, 24 Mar 2010 11:29:36 +0000 (UTC) Received: from mail-fx0-f220.google.com (mail-fx0-f220.google.com [209.85.220.220]) by pigeon.gentoo.org (Postfix) with ESMTP id 4878BE07F9 for ; Wed, 24 Mar 2010 11:29:12 +0000 (UTC) Received: by fxm20 with SMTP id 20so5273937fxm.12 for ; Wed, 24 Mar 2010 04:29:11 -0700 (PDT) Received: by 10.223.64.205 with SMTP id f13mr2157043fai.98.1269430151378; Wed, 24 Mar 2010 04:29:11 -0700 (PDT) Received: from pomiocik (s145.wifi.put.poznan.pl [150.254.132.146]) by mx.google.com with ESMTPS id 31sm12438970fkt.19.2010.03.24.04.29.10 (version=SSLv3 cipher=RC4-MD5); Wed, 24 Mar 2010 04:29:10 -0700 (PDT) Sender: Spam Box Date: Wed, 24 Mar 2010 12:28:38 +0100 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Unification of variables used within SCM eclasses Message-ID: <20100324122838.0cd4e330@pomiocik> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.19.7; 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-SHA1; boundary="Sig_/dxPHACjFO6GAjYp.Ov.QeW6"; protocol="application/pgp-signature" X-Archives-Salt: 4340bc44-8b53-4763-8a90-fec291466d64 X-Archives-Hash: ffdc2eed534f4867fc6b873d92ceb018 --Sig_/dxPHACjFO6GAjYp.Ov.QeW6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As suggested by ssuominen on bug #311101, I am posting the issue to the mailing list. Currently, various SCM eclasses differ very much in the subset of features and control variables implemented. The idea is to establish a single subset of such variables and rules for all SCM eclasses to follow, and maybe even develop a common scm.eclass which would be sourced by other SCM eclasses. Variables suggested by me: a) Common variables - the variables which would have to be used by various SCM eclasses as default/fallback values. 1. ESCM_DISTDIR (defaulting to PORTAGE_ACTUAL_DISTDIR/PORTDIR) - an alternate parent dir to all SCM stores. It would be useful if user would like to use an small file-inefficient filesystem for main DISTDIR or rsync it with other machine (where SCM files are not as important as the tarballs are). 2. ESCM_OFFLINE (most eclasses use it already) - a common switch to easily switch off all network interaction. 3. ESCM_LIVE_FAIL_IF_REPO_NOT_UPDATED (similar to the one in git.eclass) - a common switch to force unpack() phase to fail if no updates were found during the pull/update. b) Common eclass-specific variables - these ones should allow user to override above variables for single SCM. 1. E*_STORE_DIR (defaulting to ${ESCM_DISTDIR}/*-src) - already used by few eclasses, allowing user to change the location where SCM-specific clones are stored. 2. E*_OFFLINE (defaulting to ${ESCM_OFFLINE}) - allowing user to override global 'offline switch'. Thus, it should also support setting 'false' value to enable network interaction for single SCM. 3. E*_LIVE_FAIL_... - another override for the global one. 4. E*_REPO_URI - the URI to the main repository. It might be extended to support multiple URIs. 5. E*_REVISION - explicit expected-revision/tag specification, preferably along with implicit one (e.g. in ESVN_REPO_URI) deprecation. This would allow applications to easily distinguish between 'real' live ebuilds and snapshot ones fetching directly from the repo. c) Common export variables - these ones should be exported by SCM eclass and stored in environment.bz2 after successful emerge. 1. E*_VERSION (or _REVISION, or ...) - the version/revision to which the package was updated. This would be useful to determine whether the current repo is newer than one used when merging package. 2. E*_WC_PATH - the absolute path to the last-used clone dir (i.e. ${E*_STORE_DIR}/sth) and thus the most probable location to perform further updates in. d) Other: 1. ESCM_CUSTOM_FETCH - this one is not directly related to eclasses but for use of ebuild authors. Setting this in an ebuild should notice applications that the ebuild does use custom fetching procedures (i.e. fetches from multiple repositories in a manner unsupported directly by the eclass) and thus external applications should not try to update the repository themselves. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/dxPHACjFO6GAjYp.Ov.QeW6 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkup92sACgkQnGSe5QXeB7vjQACeM/0mLFwln3At102GN8skUEtm gRgAnR9pItiVXJt3UXuE4xk76wResSRN =l5fz -----END PGP SIGNATURE----- --Sig_/dxPHACjFO6GAjYp.Ov.QeW6--