Re: [gentoo-dev] Please don't turn this into a pissing match. (was: pkg_pretend USE validation and VALID_USE alternative)
On 1 April 2010 19:23, Nirbheek Chauhan wrote: > I don't want to point fingers in any one direction, [...] but I would > really like it if the volatile mix of paludis/pkgcore developers would > not explode all over the mailing list. Please don't let the discussions > get personal. But you _should_ point fingers. The only way to make sure we have civil discussions is to point out bad behavior and let people know we don't tolerate that. And when such behavior is displayed repeatedly, we should exclude such people from taking part in our discussions. We don't need poisonous people, so let's get rid of them. Cheers, -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] 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 Pawlikkey id: 0xF6A80E46
desktop-misc, java, apache, ppc, vim, kernel, python...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Unification of variables used within SCM eclasses
On Fri, 02 Apr 2010 19:45:44 +0100
Krzysztof Pawlik 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
signature.asc
Description: PGP signature
Re: [gentoo-dev] Please don't turn this into a pissing match. (was: pkg_pretend USE validation and VALID_USE alternative)
On Fri, Apr 2, 2010 at 6:56 PM, Ben de Groot wrote: > On 1 April 2010 19:23, Nirbheek Chauhan wrote: >> I don't want to point fingers in any one direction, [...] but I would >> really like it if the volatile mix of paludis/pkgcore developers would >> not explode all over the mailing list. Please don't let the discussions >> get personal. > > But you _should_ point fingers. The only way to make sure we have > civil discussions is to point out bad behavior and let people know > we don't tolerate that. And when such behavior is displayed > repeatedly, we should exclude such people from taking part in > our discussions. We don't need poisonous people, so let's > get rid of them. > I didn't personally point fingers in this case because me doing so in that discussion would not have been taken as a neutral party stance. Besides both sides were being childish; and sending one mail is easier than 2-3 ;p Neutral parties are constantly encouraged to put a stop to anti-social behaviour by polite means (and escalate when necessary). We don't like to see bytes being wasted on unproductive discussions, but we don't want a witch-hunt either :) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] pkg_pretend USE validation and VALID_USE alternative
On Thursday 01 April 2010 19:39:43 Dror Levin wrote: > Here's another suggestion: how about we don't impose any ridiculous > constraints on development and keep this discussion on the technological > side of the original proposal? It's not ridiculous to expect to have a new EAPI in a reasonable amount of time. Other features are already done, so holding them back until this one is complete would itself be placing constraints on developers who have a use for the other features.
Re: [gentoo-dev] GSoC
On 20:59 Wed 31 Mar , Serheo wrote: > Google summer of code test message. Sorry for interuption. You might want to consider the impression you make on people when you send an email like this. When you're required to send an email, why not make it something useful and get people excited about your proposal? -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com
