Hi,
sorry for the late reply.
Michał Górny gen...@mgorny.alt.pl:
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
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
URL:http://gentoo.faulhammer.org/
signature.asc
Description: PGP signature
