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 1Nxlsl-00021q-JW for garchives@archives.gentoo.org; Fri, 02 Apr 2010 18:46:15 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CFD2DE096D; Fri, 2 Apr 2010 18:46:11 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id A56EBE092A for ; Fri, 2 Apr 2010 18:45:48 +0000 (UTC) Received: from [10.10.10.11] (unknown [79.97.72.198]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 877071B4046 for ; Fri, 2 Apr 2010 18:45:47 +0000 (UTC) Message-ID: <4BB63B58.8030007@gentoo.org> Date: Fri, 02 Apr 2010 19:45:44 +0100 From: Krzysztof Pawlik Organization: Gentoo User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100326 Thunderbird/3.0.3 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Unification of variables used within SCM eclasses References: <20100324122838.0cd4e330@pomiocik> In-Reply-To: <20100324122838.0cd4e330@pomiocik> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig362AF636625870C2A19C8C9D" X-Archives-Salt: eb5ee908-88d6-4ab6-a18c-8007c2d6cd36 X-Archives-Hash: 2c3201e9abb7798c3bbec7783a8daad9 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig362AF636625870C2A19C8C9D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/24/10 11:28, Micha=C5=82 G=C3=B3rny wrote: > As suggested by ssuominen on bug #311101, I am posting the issue > to the mailing list. >=20 > 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. Overall: I like the idea of common vcs.eclass - that would make easier no= t only to use/write ebuilds using various VCS'es but also to maintain the eclass= es. > Variables suggested by me: >=20 > a) Common variables - the variables which would have to be used by > various SCM eclasses as default/fallback values. >=20 > 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). >=20 > 2. ESCM_OFFLINE (most eclasses use it already) > - a common switch to easily switch off all network interaction. >=20 > 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. What about ESCM_REVISION defaulting to empty value meaning to use head/ti= p/etc revision? > b) Common eclass-specific variables - these ones should allow user to > override above variables for single SCM. >=20 > 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. Is it really necessary? Can't we switch to one, common vcs-src/ (or somet= hing like this) directory? > 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. If there's a ESCM_OFFLINE is it necessary to copy the information again t= o vcs-specific eclasses? I don't think so. In other words: I don't think th= at copying variables from parent eclass to vcs-specific one has any point. > 3. E*_LIVE_FAIL_... > - another override for the global one. >=20 > 4. E*_REPO_URI > - the URI to the main repository. It might be extended to support > multiple URIs. >=20 > 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. >=20 > c) Common export variables - these ones should be exported by SCM eclas= s > and stored in environment.bz2 after successful emerge. >=20 > 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. >=20 > 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. >=20 > d) Other: >=20 > 1. ESCM_CUSTOM_FETCH > - this one is not directly related to eclasses but for use of ebuil= d > 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. Overall: looks good. It would be extremely helpful if we could discuss an= actual implementation, setting up a repo and starting work there may be an aweso= me idea. --=20 Krzysztof Pawlik key id: 0xF6A80E46 desktop-misc, java, apache, ppc, vim, kernel, python... --------------enig362AF636625870C2A19C8C9D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLtjtYAAoJEBZyv1r2qA5GcLgH/RpxRXLyfxQrnIQpAjtkS9bC LQ7HgYpLb7JubK91cvhgcE3DpbCyxl+o3FjMjox7sOD4SzHCPxSfQWaSXwOzhZnE tD7ks7FpOcjAbh8tjgTH4aDSqfdinoQk+um2QaXGdFPKL0TyCLIjAk7jv2xJLZll 1gjVyEZZQhAuA+z8ctyLk7cLWBwWz48PXUMfTmlLp9Lvo9PsqFVtTgDUGsNAyOjt doMRWhhQ9xSRQ4yUY580gB4JMFsu6NuDMXe6HDjqutsZcOcFmX9w0ItbujgGqD+2 omKM1T40aRvyWO74uT+XWs6QqDsct1lZe2T4nwLW5u0BoXgBSaX6MNnY2Ckzaro= =LZ7Q -----END PGP SIGNATURE----- --------------enig362AF636625870C2A19C8C9D--