FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 03-24-2010, 10:28 AM
Michał Górny
 
Default Unification of variables used within SCM eclasses

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>
 
Old 03-24-2010, 04:05 PM
Duncan
 
Default Unification of variables used within SCM eclasses

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
 
Old 04-02-2010, 06:45 PM
Krzysztof Pawlik
 
Default Unification of variables used within SCM eclasses

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...
 
Old 04-02-2010, 07:18 PM
Michał Górny
 
Default Unification of variables used within SCM eclasses

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>
 
Old 04-12-2010, 08:10 AM
Christian Faulhammer
 
Default Unification of variables used within SCM eclasses

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

Thread Tools




All times are GMT. The time now is 12:01 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org