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...
signature.asc
Description: OpenPGP digital signature
