[gentoo-dev] DEFAULT_* proposal

[gentoo-dev] DEFAULT_* proposal

[Thomas Anderson]

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

[RFC] Simplifying functions with variables and help from the PM

Hello All;
	This is a reposting of a call for discussion on DEFAULT_* variables.
	The original discussion was at [1]. The general idea is making the
	default functions support some new variables so that they are more
	flexible. 

	Here are the function(in order of execution) changes I propose, but
	let me first remind you that these changes are for the default
	package manager implementation of the functions. Each proposal is
	separate but it'd be nice if they all went in the same EAPI so it
	doesn't get confusing.

		src_prepare:
			DEFAULT_RSC_PREPARE_PATCHES[]
			This is a bash arrary list of patches to be applied to the
			sources. This is implemented as PATCHES or similar variables
			in a lot of eclasses like base, bzr, git, horde, kde, ruby,
			ruby-gnome2, subversion and x-modular but they all have unneeded
			differences. We'll need a function(say builtin_epatch, but 
			better names are needed) in the PM to handle patching.

		src_configure:
			DEFAULT_SRC_CONFIGURE_USE_ENABLES[]
			An array whose constants are passed as arguments to
			`use_enable`. Each value of the array can have two parts.
			DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'a52 a52dec' ) would
			translate to $(use_enable a52 a52dec).

			DEFAULT_SRC_CONFIGURE_USE_WITHS[]
			Same as above, but s/enable/with/

			DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS[]
			Array of options to pass to econf

		src_compile:
			DEFAULT_SRC_COMPILE_PARAMS[]
			Array of options to pass to emake

		src_install:
			All I want changed here is a variable for a list of extra docs to be
			installed. This'll require a default function for
			src_install and I propose:
				src_install() {
					emake -j1 install DESTDIR="${D}" || die "make install died"
					[[ -n ${DEFAULT_SRC_INSTALL_DOCS} ]] && dodoc \
					${DEFAULT_SRC_INSTALL_DOCS}
				}
			bug #33544 has more information on this topic, as does
			tommy's recent thread on the subject of default src_install
			function.

	In my experience, these features greatly enhance ebuilds and make
	the ebuilds simpler to write(before objecting to this point, read
	the original thread[1] and/or use the feature), read, and maintain.

	Also, one point I cannot stress enough is that this is not meant for
	every ebuild but for the majority of simple cases.

	Now, last time around, objections were made to the effect that the
	src_configure proposal hides things in the PM which makes the
	learning curve higer and hides things from the ebuild viewer. My
	position on this is that it hides stuff in the same way that
	`use_enable mp3` hides `use mp3 && echo "--enable-mp3" || echo
	"--disable-mp3"`. In other words, not all cases where you move
	thinsg to the PM are bad.

	Credit for this idea goes to those who made the exheres package
	format(used for the Exherbo linux distribution) and those who
	participated in the discussion on bug #33544 over the past who knows
	how many years.

Please discuss!
Thomas Anderson



[1]: http://article.gmane.org/gmane.linux.gentoo.devel/58038

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] DEFAULT_* proposal

[Thomas Sachau]

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

Thomas Anderson schrieb:
> 		src_install:
> 			All I want changed here is a variable for a list of extra docs to be
> 			installed. This'll require a default function for
> 			src_install and I propose:
> 				src_install() {
> 					emake -j1 install DESTDIR="${D}" || die "make install died"
> 					[[ -n ${DEFAULT_SRC_INSTALL_DOCS} ]] && dodoc \
> 					${DEFAULT_SRC_INSTALL_DOCS}
> 				}
> 			bug #33544 has more information on this topic, as does
> 			tommy's recent thread on the subject of default src_install
> 			function.

At least for this one, why dont you use my proposal?

-default should always be unlimited emake, so no -j1
-Why die, if emake fails because of missing makefile (as meta ebuilds tend to have)?
-Why not check for some default docs and install them if they exist and make dodoc die on error?

this is at least, what my latest proposal does:

src_install() {
	if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
		emake DESTDIR="${D}" install || die "emake install failed"
	fi
	if [ -n "${DOCS}" ]; then
		dodoc ${DOCS} || die "dodoc failed"
	else
		for x in AUTHORS ChangeLog NEWS README; do
			if [ -e ${x} ]; then
				dodoc ${x} || die "dodoc ${x} failed"
			fi
		done
	fi
}

The rest of the proposal looks acceptable to me.


-- 
Thomas Sachau

Gentoo Linux Developer


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

Re: [gentoo-dev] DEFAULT_* proposal

[Peter Volkov]

В Сбт, 08/11/2008 в 17:20 -0500, Thomas Anderson пишет:
> This is a reposting of a call for discussion on DEFAULT_* variables.
> The original discussion was at [1].

How does this proposal answers concerns raised during last discussion?

I did my best and reread all the discussions and both proposals. I found
two reasons supporting this change is that it makes ebuilds more
"flexible"[1] or "much simpler"[2]. With all due respect I disagree.

1. Functions we have now are much more flexible then proposed arrays. Do
I need to think of some example of code that is impossible to do with
arrays but still possible with functions?

2. Much simpler? No, it's not:

(2.1) Such arrays do not not reduce the number of keys to be pressed.
They require even more typing for small ebuilds [3] (example proposed by
you, btw) and the only example which expose some improvement (presented
by Santiago M. Mola[4]) shows that we still didn't learned how to use
syntax we already have and (2.2) some extensions to the current syntax
will just complicate things. Look if you remove $myconf variable from
that ebuild[4], remove || die after econf and in EAPI=2 you can drop
emake || die you'll see that the gain is small even for such medium size
ebuild.

At the same time this new syntax make some things worse:

1. it hides real code under this variables.

2. having variable like DEFAULT_RSC_PREPARE_PATCHES will promote bad
practice of using patches instead of sed.

3. SUCH_LONG_VARIABLES_IN_CAPS are always harder to read [5] and thus
easier to do typo in them (like you did in DEFAULT_RSC_PREPARE_PATCHES,
btw). (highlighting helps here but does not makes that variables easier
to read or type in?)

4. "it also conflates multiple concepts into a single variable name (the
function name, whether it's USE-dependent, and how the configure flag is
passed)." (-- Donnie Berkholz [6])

5. "One of the great things about ebuilds is that they're very natural
to write in most cases, if you can manage to build the program by hand.
Raising this barrier of entry for questionable benefit seems like a bad 
idea." (-- Donnie Berkholz [7])


So, why to reiterate this discussion without providing clear answer to
the above concerns?


At the same time default src_install is different proposal and having it
implemented is a good idea.


[1] http://article.gmane.org/gmane.linux.gentoo.devel/57990
[2] http://article.gmane.org/gmane.linux.gentoo.devel/58728
[3] http://thread.gmane.org/gmane.linux.gentoo.devel/57990
[4] http://article.gmane.org/gmane.linux.gentoo.devel/57996
[5] http://archive.devwebpro.com/devwebpro-39-200305063ReasonsNotToUseUppercase.html
[6] http://article.gmane.org/gmane.linux.gentoo.devel/58061
[7] http://article.gmane.org/gmane.linux.gentoo.devel/58051

-- 
Peter.

Re: [gentoo-dev] DEFAULT_* proposal

[Thomas Anderson]

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

On Sun, Nov 09, 2008 at 03:39:12PM +0300, Peter Volkov wrote:
> В Сбт, 08/11/2008 в 17:20 -0500, Thomas Anderson пишет:
> > This is a reposting of a call for discussion on DEFAULT_* variables.
> > The original discussion was at [1].
> 1. Functions we have now are much more flexible then proposed arrays. Do
> I need to think of some example of code that is impossible to do with
> arrays but still possible with functions?

And more complex. Remember, I said that these proposals were not for
every case. Showing how it can't be used in one case says nothing about
it otherwise being used.

> 2. Much simpler? No, it's not:
> 
> (2.1) Such arrays do not not reduce the number of keys to be pressed.
> They require even more typing for small ebuilds [3] (example proposed by
> you, btw) and the only example which expose some improvement (presented
> by Santiago M. Mola[4]) shows that we still didn't learned how to use
> syntax we already have and (2.2) some extensions to the current syntax
> will just complicate things. Look if you remove $myconf variable from
> that ebuild[4], remove || die after econf and in EAPI=2 you can drop
> emake || die you'll see that the gain is small even for such medium size
> ebuild.
> At the same time this new syntax make some things worse:

Here's an example of how much gain there is with this approach:
http://tinyurl.com/6jj8a5

> 1. it hides real code under this variables.
As mentioned, so do use_enable, use_with, emake(though these are
functions hiding code, DOCS. Hiding code is not always a bad thing.

> 2. having variable like DEFAULT_RSC_PREPARE_PATCHES will promote bad
> practice of using patches instead of sed.

How so? We already have a ton of PATCHES variables as mentioned. How is
this standardization of what we already have going to promote bad
practices?

> 3. SUCH_LONG_VARIABLES_IN_CAPS are always harder to read [5] and thus
> easier to do typo in them (like you did in DEFAULT_RSC_PREPARE_PATCHES,
> btw). (highlighting helps here but does not makes that variables easier
> to read or type in?)

Ok, so you could find a different name. The names aren't really
important. You could use USE_ENABLES and USE_WITHS and DEFAULT_PATCHES.

> 4. "it also conflates multiple concepts into a single variable name (the
> function name, whether it's USE-dependent, and how the configure flag is
> passed)." (-- Donnie Berkholz [6])
> 
> 5. "One of the great things about ebuilds is that they're very natural
> to write in most cases, if you can manage to build the program by hand.
> Raising this barrier of entry for questionable benefit seems like a bad 
> idea." (-- Donnie Berkholz [7])

No one is raising the barrier. People can continue to use use_enable and
use_with as they have for ages. The only thing that changes is that
ebuild devs now have another way(which is simpler from my experience and
that of others) to write ebuilds. Also, it's not that more

> 
> So, why to reiterate this discussion without providing clear answer to
> the above concerns?
> 
Because we came up with a more comprehensive proposal covering more
phase functions.
> 
> At the same time default src_install is different proposal and having it
> implemented is a good idea.
> 
> 
> [1] http://article.gmane.org/gmane.linux.gentoo.devel/57990
> [2] http://article.gmane.org/gmane.linux.gentoo.devel/58728
> [3] http://thread.gmane.org/gmane.linux.gentoo.devel/57990
> [4] http://article.gmane.org/gmane.linux.gentoo.devel/57996
> [5] http://archive.devwebpro.com/devwebpro-39-200305063ReasonsNotToUseUppercase.html
> [6] http://article.gmane.org/gmane.linux.gentoo.devel/58061
> [7] http://article.gmane.org/gmane.linux.gentoo.devel/58051
> 
> -- 
> Peter.
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] DEFAULT_* proposal

[Santiago M. Mola]

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

Hello,

El dom, 09-11-2008 a las 15:39 +0300, Peter Volkov escribió:
> 
> 1. Functions we have now are much more flexible then proposed arrays. Do
> I need to think of some example of code that is impossible to do with
> arrays but still possible with functions?
> 

The same concern was raised in the default src_install proposal. Making
default functions a bit more flexible doesn't mean we need default
functions which cover every possible case, that's just impossible.

> 
> At the same time this new syntax make some things worse:

> 
> 2. having variable like DEFAULT_RSC_PREPARE_PATCHES will promote bad
> practice of using patches instead of sed.

As shown in the proposal, this variable is already used in many eclasses
and it has been proven useful.

I'm not sure the existence of PATCHES is promoting any kind of "patch
abuse". As far as I know, it's more common the concern about abusing sed
for things that should be patched rather than the other way.

But, in any case, both methods would still be available:

	src_prepare {
		epatch "${FILESDIR}"/some-stuff.patch
		sed -i -e "s:FOO:BAR:g" Makefile
	}

would still be correct.

If someone is using the PATCHES variable like this:

	PATCHES=( 'stome-stuff.patch' 'more-patches.patch' ... ... ... )

a sed call would be easy to add if needed as follows:

	PATCHES=( 'stome-stuff.patch' 'more-patches.patch' ... ... ... )

	src_prepare() {
		default
		sed -i -e "s:FOO:BAR:g" Makefile
	}


It's quite straight-forward.

> 3. SUCH_LONG_VARIABLES_IN_CAPS are always harder to read [5] and thus
> easier to do typo in them (like you did in DEFAULT_RSC_PREPARE_PATCHES,
> btw). (highlighting helps here but does not makes that variables easier
> to read or type in?)

This is the easier part to address. If these names are a problem, other
names can be used. For example, what it's called
DEFAULT_SRC_INSTALL_DOCS in this proposal, it's called just DOCS in
others.

If people likes this approach better, then similar names can be chosen
for the rest of proposed variables. For example:

DEFAULT_SRC_PREPARE_PATCHES -> PATCHES, EPATCHES...
DEFAULT_SRC_CONFIGURE_ENABLES -> ECONF_ENABLES
DEFAULT_SRC_COMPILE_PARAMS -> EMAKE_PARAMS, EMAKE_EXTRA_PARAMS...

Anyway, it'd be better if people focus on discussing the actual
functionality rather than the chosen names.

> 
> 4. "it also conflates multiple concepts into a single variable name (the
> function name, whether it's USE-dependent, and how the configure flag is
> passed)." (-- Donnie Berkholz [6])

ECONF_USE_ENABLES might solve that problem.

> 
> 5. "One of the great things about ebuilds is that they're very natural
> to write in most cases, if you can manage to build the program by hand.
> Raising this barrier of entry for questionable benefit seems like a bad 
> idea." (-- Donnie Berkholz [7])

Functions would still be overridable. And, in fact, they will need to be
overriden in many cases. There's no change there. With respect this
"barrier", it already exists with the many eclasses we have.

Regards,
-- 
Santiago Moisés Mola
Jabber: cooldwind@gmail.com | GPG: AAD203B5

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] DEFAULT_* proposal

[Peter Volkov]

Well for myself I found compromise. Although in both proposals as I see
you've omitted part where you'll discuss how you are going to implement
this feature, implementing this feature as eclass addresses most of my
concerns, since:

1. ebuild's syntax does not change
2. people will have to inherit some.eclass to use them and thus will do
this only when it's really saves time/efforts

I've dropped all other answers I was going to give you since I started
to feel that this is just another cycle. We can discuss them off list if
necessary. :)

-- 
Peter.