public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <gentoo@mgorny.alt.pl>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Unification of variables used within SCM eclasses
Date: Wed, 24 Mar 2010 12:28:38 +0100	[thread overview]
Message-ID: <20100324122838.0cd4e330@pomiocik> (raw)

[-- Attachment #1: Type: text/plain, Size: 3112 bytes --]

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.

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.

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.

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.

-- 
Best regards,
Michał Górny

<http://mgorny.alt.pl>
<xmpp:mgorny@jabber.ru>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

             reply	other threads:[~2010-03-24 11:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-24 11:28 Michał Górny [this message]
2010-03-24 17:05 ` [gentoo-dev] Re: Unification of variables used within SCM eclasses Duncan
2010-04-02 18:45 ` [gentoo-dev] " Krzysztof Pawlik
2010-04-02 19:18   ` Michał Górny
2010-04-12  8:10 ` [gentoo-dev] " Christian Faulhammer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100324122838.0cd4e330@pomiocik \
    --to=gentoo@mgorny.alt.pl \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox