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

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

[Michał Górny]

[-- 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 --]

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

[Duncan]

Michał Górny posted on Wed, 24 Mar 2010 12:28:38 +0100 as excerpted:

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

Reasonable idea...

The standard note here every time source control comes up, however, is 
that SCM is ambiguous, conflicting with scheme (the language).  VCS 
(version control system) seems to be the preferred alternative.

I'll let the various VCS eclass using devs worry about the details...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Krzysztof Pawlik]

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 554 bytes --]

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

[Michał Górny]

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

On Fri, 02 Apr 2010 19:45:44 +0100
Krzysztof Pawlik <nelchael@gentoo.org> wrote:

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

ESCM_* variables would rather be set on a global basis (in make.conf or
calling env), not in specific ebuild.

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

I don't see any real benefits of using single directory, and we would
either have to move all existing repos (which would break backwards
compat and will probably have at least one serious issues) or force
user to refetch all of them. Just after a month or two ago shklee had
to it anyway due to changes in git.eclass.

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

True. But this particular var is already defined in few eclasses, and I
really do not want to break compat.

And last of all, as I should have mentioned earlier, I would like
to avoid raising a revolution. I would rather like developing some
common feature list based on what eclasses currently do, and adding
missing ones to particular eclasses.

-- 
Best regards,
Michał Górny

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

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

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

[Christian Faulhammer]

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

Hi,

sorry for the late reply.

Michał Górny <gentoo@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/>

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