Re: [gentoo-dev] Unification of variables used within SCM eclasses

[Krzysztof Pawlik]

On 03/24/10 11:28, Michał Górny wrote:
> 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.

Overall: I like the idea of common vcs.eclass - that would make easier not only
to use/write ebuilds using various VCS'es but also to maintain the 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.

What about ESCM_REVISION defaulting to empty value meaning to use head/tip/etc
revision?

> 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.

Is it really necessary? Can't we switch to one, common vcs-src/ (or something
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 to
vcs-specific eclasses? I don't think so. In other words: I don't think that
copying variables from parent eclass to vcs-specific one has any point.

> 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.

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 awesome idea.

-- 
Krzysztof Pawlik  <nelchael at gentoo.org>  key id: 0xF6A80E46
desktop-misc, java, apache, ppc, vim, kernel, python...