Hi, sorry for the late reply. Michał Górny : > 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). Sounds reasonable, though mostly a nice-have. > 2. ESCM_OFFLINE (most eclasses use it already) > - a common switch to easily switch off all network interaction. Crucial, at least for me. :) > 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. Something better named would be great...it looks just stupid in make.conf. > 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. Ok with those. > 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. Those are not really user settings, but defined by the using ebuild. > 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. Portage team should comment here, maybe. What is the use case for this, honestly? > 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. Use case? V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode