[gentoo-dev] RFC: sh versionator.eclass

[gentoo-dev] RFC: sh versionator.eclass

[Roy Marples]

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

I would like to propse a new versionator.eclass for consideration (attached).

This version, I believe, is more readable and maintainable then the one 
currently in portage. It also uses a lot less code and has the bonus of being 
pure sh.

It has not been tested in any ebuilds, but it does pass the self test from 
portage as it stands. No doubt the nit pickers can invent new tests where 
this one fails and the current one does not - I shall address this when they 
do.

Comments are welcome.

Thanks

Roy

[-- Attachment #2: versionator.eclass --]
[-- Type: text/plain, Size: 10429 bytes --]

# Copyright 2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

# sh version of versionator.eclass

# get_last_version_component_index implementation is not implemented because
# 1) The name encourages the use of bash arrarys
# 2) User could do $(($(get_version_component_count) - 1)) to achieve the
#    same result

_get_all_version_components() {
	local dosep=$1 ver=${2:-${PV}} x= last= this=

	while [ -n "${ver}" ]; do
		x=$(printf "%c" "${ver}")
		case "${x}" in
			[0-9]) this="digit";;
			-|.|_) this="sep";;
			*)     this="alpha";;
		esac
		if ${dosep} || [ "${this}" != "sep" ]; then
			[ -n "${last}" -a "${this}" != "${last}" ] && printf " "
			printf "%c" "${x}"
		fi
		last=${this}
		ver=${ver#${x}}
	done
}

# Split up a version string into its component parts. If no parameter is
# supplied, defaults to $PV.
#     0.8.3       ->  0 . 8 . 3
#     7c          ->  7 c
#     3.0_p2      ->  3 . 0 _ p2
#     20040905    ->  20040905
#     3.0c-r1     ->  3 . 0 c - r1
get_all_version_components() {
	_get_all_version_components true "$@"
}

# Get the important version components, excluding '.', '-' and '_'. Defaults to
# $PV if no parameter is supplied.
#     0.8.3       ->  0 8 3
#     7c          ->  7 c
#     3.0_p2      ->  3 0 p2
#     20040905    ->  20040905
#     3.0c-r1     ->  3 0 c r1
get_version_components() {
	_get_all_version_components false "$@"
}

# Get the major version of a value. Defaults to $PV if no parameter is supplied.
#     0.8.3       ->  0
#     7c          ->  7
#     3.0_p2      ->  3
#     20040905    ->  20040905
#     3.0c-r1     ->  3
get_major_version() {
	set -- $(get_version_components "$@")
	printf "%s" "$1"
}

# Get everything after the major version and its separator (if present) of a
# value. Defaults to $PV if no parameter is supplied.
#     0.8.3       ->  8.3
#     7c          ->  c
#     3.0_p2      ->  0_p2
#     20040905    ->  (empty string)
#     3.0c-r1     ->  0c-r1
get_after_major_version() {
	printf "%s" "${@#$(get_major_version "$@")}"
}

_replace_version_separator_n() {
	local n=$1 sep=$2 i=0

	set -- $(get_all_version_components "$3")
	while [ -n "$1" ]; do
		case "$1" in
			-|.|_)
				i=$((${i} + 1))
				if [ "${i}" = "${n}" ]; then
					printf "%s" "${sep}"
				else
					printf "%s" "$1"
				fi
				;;
			*)
				printf "%s" "$1"
				;;
		esac
		shift
	done
}

_replace_version_separator_a() {
	local n=$1 sep=$2 i=0

	set -- $(get_all_version_components "$3")
	while [ -n "$1" ]; do
		if [ "${n}" = "$1" ]; then
			printf "%s" "${sep}"
			n=
		else
			printf "%s" "$1"
		fi
		shift
	done
}

# Replace the $1th separator with $2 in $3 (defaults to $PV if $3 is not
# supplied). If there are fewer than $1 separators, don't change anything.
#     1 '_' 1.2.3       -> 1_2.3
#     2 '_' 1.2.3       -> 1.2_3
#     1 '_' 1b-2.3      -> 1b_2.3
# Rather than being a number, $1 can be a separator character such as '-', '.'
# or '_'. In this case, the first separator of this kind is selected.
replace_version_separator() {
	case "$1" in
		[0-9]*) _replace_version_separator_n "$@";;
		*)      _replace_version_separator_a "$@";;
	esac
}

# Replace all version separators in $2 (defaults to $PV) with $1.
#     '_' 1b.2.3        -> 1b_2_3
replace_all_version_separators() {
	local sep=$1

	set -- $(get_all_version_components "$2")
	while [ -n "$1" ]; do
		case "$1" in
			-|.|_) printf "%s" "${sep}";;
			*)     printf "%s" "$1";;
		esac
		shift
	done
}

# Delete the $1th separator in $2 (defaults to $PV if $2 is not supplied). If
# there are fewer than $1 separators, don't change anything.
#     1 1.2.3       -> 12.3
#     2 1.2.3       -> 1.23
#     1 1b-2.3      -> 1b2.3
# Rather than being a number, $1 can be a separator character such as '-', '.'
# or '_'. In this case, the first separator of this kind is deleted.
delete_version_separator() {
	replace_version_separator "$1" "" "$2"
}

# Delete all version separators in $1 (defaults to $PV).
#     1b.2.3        -> 1b23
delete_all_version_separators() {
	replace_all_version_separators "" "$@"
}

# How many version components are there in $1 (defaults to $PV)?
#     1.0.1       ->  3
#     3.0c-r1     ->  4
get_version_component_count() {
	set -- $(get_version_components "$@")
	printf "%s" "$#"
}

# Get a particular component or range of components from the version. If no
# version parameter is supplied, defaults to $PV.
#    1      1.2.3       -> 1
#    1-2    1.2.3       -> 1.2
#    2-     1.2.3       -> 2.3
get_version_component_range() {
	[ -z "$1" ] && return 1

	local range=$(get_all_version_components "$1")
	shift
	local vers=$(get_all_version_components "$@")

	set -- ${range}
	local one=$1 two=$2 three=$3

	set -- ${vers}
	local i=1
	while [ ${i} -lt ${one} ]; do
		shift; shift
		i=$((${i} + 1))
	done

	printf "%s" "$1"
	[ "${two}" != "-" ] && return
	shift

	[ -z "${three}" ] && three=$(get_version_component_count "${vers}")
	while [ ${i} -lt ${three} ]; do
		printf "%s" "$1$2"
		shift; shift
		i=$((${i} + 1))
	done
}

_version_getn() {
	local v=$1
	case "$1" in
		0*)    v=${1##*0}; v=${v:-0};;
		-|.|_) v=0;;
	esac
	printf "%s" "${v}"
}

_version_is_prefix() {
	case "$1" in
		alpha|beta|pre|rc) return 0;;
	esac
	return 1
}

# Takes two parameters (a, b) which are versions. If a is an earlier version
# than b, returns 1. If a is identical to b, return 2. If b is later than a,
# return 3. You probably want version_is_at_least rather than this function.
# May not be very reliable. Test carefully before using this.
version_compare() {
	# Don't beat around the bush
	[ "$1" = "$2" ] && return 2

	local ver1=$(get_all_version_components "$1") ver11= ver11n=
	local ver2=$(get_all_version_components "$2") ver21= ver21n=

	while [ -n "${ver1}" -o -n "${ver2}" ]; do
		# Grab the components and trim leading 0's
		set -- ${ver1}
		ver11=$(_version_getn "$@")
		shift
		ver1="$@"
		set -- ${ver2}
		ver21=$(_version_getn "$@")
		shift
		ver2="$@"

		if _version_is_prefix "${ver11}"; then
			_version_is_prefix "${ver21}" || return 1
		else
			_version_is_prefix "${ver21}" && return 3
		fi

		[ -z "${ver11}" ] && ver11=0
		[ -z "${ver21}" ] && ver21=0

		[ "${ver11}" = "${ver21}" ] && continue

		case "${ver11}" in
			[0-9]*) ver11n=true;;
			*)      ver11n=false;;
		esac

		case "${ver21}" in
			[0-9]*) ver21n=true;;
			*)      ver21n=false;;
		esac

		if ${ver11n} && ${ver21n}; then
			# Both are numbers
			[ "${ver11}" -lt "${ver21}" ] && return 1 
			[ "${ver11}" -gt "${ver21}" ] && return 3
		fi

		# Either is not a number, so lexical comparison
		[ "${ver11}" "<" "${ver21}" ] && return 1 
		[ "${ver11}" ">" "${ver21}" ] && return 3
	done

	# All equal then
	return 2 
}

# Is $2 (defaults to $PVR) at least version $1? Intended for use in eclasses
# only. May not be reliable, be sure to do very careful testing before actually
# using this. Prod ciaranm if you find something it can't handle.
version_is_at_least() {
	version_compare "$1" "${2:-${PVR}}"
	case $? in
		1|2) return 0;;
		3)   return 1;;
		*)   die "versionator compare bug";;
	esac
}

# Returns its parameters sorted, highest version last.
version_sort() {
	local sorted= left="$@" item=

	while [ -n "${left}" ]; do
		set -- ${left}
		item=$1
		shift
		left="$@"

		set -- ${sorted}
		sorted=
		local inserted=false
		while [ -n "$1" ]; do
			version_compare "${item}" "$1"
			if [ "$?" = "1" ]; then
				sorted="${sorted}${sorted:+ }${item} $*"
				continue 2
			fi
			sorted="${sorted}${sorted:+ }$1"
			shift
		done

		sorted="${sorted}${sorted:+ }${item}"
	done

	printf "%s" "${sorted}"
}

__versionator__test_version_compare() {
	local lt=1 eq=2 gt=3 p= q=

	__versionator__test_version_compare_t() {
		version_compare "$1" "$3"
		local r=$?
		[ "${r}" != "$2" ] && echo "FAIL: ${@} (got ${r} exp $2)"
	}

	echo "
		0             $lt 1
		1             $lt 2
		2             $gt 1
		2             $eq 2
		0             $eq 0
		10            $lt 20
		68            $eq 068
		068           $gt 67
		068           $lt 69

		1.0           $lt 2.0
		2.0           $eq 2.0
		2.0           $gt 1.0

		1.0           $gt 0.0
		0.0           $eq 0.0
		0.0           $lt 1.0

		0.1           $lt 0.2
		0.2           $eq 0.2
		0.3           $gt 0.2

		1.2           $lt 2.1
		2.1           $gt 1.2

		1.2.3         $lt 1.2.4
		1.2.4         $gt 1.2.3

		1.2.0         $eq 1.2
		1.2.1         $gt 1.2
		1.2           $lt 1.2.1

		1.2b          $eq 1.2b
		1.2b          $lt 1.2c
		1.2b          $gt 1.2a
		1.2b          $gt 1.2
		1.2           $lt 1.2a

		1.3           $gt 1.2a
		1.3           $lt 1.3a

		1.0_alpha7    $lt 1.0_beta7
		1.0_beta      $lt 1.0_pre
		1.0_pre5      $lt 1.0_rc2
		1.0_rc2       $lt 1.0

		1.0_p1        $gt 1.0
		1.0_p1-r1     $gt 1.0_p1

		1.0_alpha6-r1 $gt 1.0_alpha6
		1.0_beta6-r1  $gt 1.0_alpha6-r2

		1.0_pre1      $lt 1.0-p1

		1.0p          $gt 1.0_p1
		1.0r          $gt 1.0-r1
		1.6.15        $gt 1.6.10-r2
		1.6.10-r2     $lt 1.6.15

	" | while read a b c ; do
		[ -z "${a}${b}${c}" ] && continue;
		__versionator__test_version_compare_t "${a}" "${b}" "${c}"
	done


	for q in "alpha beta pre rc=${lt};${gt}" "p r=${gt};${lt}" ; do
		for p in ${q%%=*} ; do
			local c=${q##*=}
			local alt=${c%%;*} agt=${c##*;}
			__versionator__test_version_compare_t "1.0" $agt "1.0_${p}"
			__versionator__test_version_compare_t "1.0" $agt "1.0_${p}1"
			__versionator__test_version_compare_t "1.0" $agt "1.0_${p}068"

			__versionator__test_version_compare_t "2.0_${p}"    $alt "2.0"
			__versionator__test_version_compare_t "2.0_${p}1"   $alt "2.0"
			__versionator__test_version_compare_t "2.0_${p}068" $alt "2.0"

			__versionator__test_version_compare_t "1.0_${p}"  $eq "1.0_${p}"
			__versionator__test_version_compare_t "0.0_${p}"  $lt "0.0_${p}1"
			__versionator__test_version_compare_t "666_${p}3" $gt "666_${p}"

			__versionator__test_version_compare_t "1_${p}7"  $lt "1_${p}8"
			__versionator__test_version_compare_t "1_${p}7"  $eq "1_${p}7"
			__versionator__test_version_compare_t "1_${p}7"  $gt "1_${p}6"
			__versionator__test_version_compare_t "1_${p}09" $eq "1_${p}9"
		done
	done

	for p in "-r" "_p" ; do
		__versionator__test_version_compare_t "7.2${p}1" $lt "7.2${p}2"
		__versionator__test_version_compare_t "7.2${p}2" $gt "7.2${p}1"
		__versionator__test_version_compare_t "7.2${p}3" $gt "7.2${p}2"
		__versionator__test_version_compare_t "7.2${p}2" $lt "7.2${p}3"
	done
}

Re: [gentoo-dev] RFC: sh versionator.eclass

[Roy Marples]

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

On Monday 01 October 2007 22:59:40 Roy Marples wrote:
> This version, I believe, is more readable and maintainable then the one
> currently in portage. It also uses a lot less code and has the bonus of
> being pure sh.

It should be noted that that first draft was developed on bash only.
Attached is a patch that fixes quoting on all shells and shift errors on 
ash/dash/busybox variants.

Also attached is the patched versionater.eclass again.

Thanks

Roy

[-- Attachment #2: versionator.eclass --]
[-- Type: text/plain, Size: 10467 bytes --]

# Copyright 2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

# sh version of versionator.eclass

# get_last_version_component_index implementation is not implemented because
# 1) The name encourages the use of bash arrarys
# 2) User could do $(($(get_version_component_count) - 1)) to achieve the
#    same result

_get_all_version_components() {
	local dosep=$1 ver=${2:-${PV}} x= last= this=

	while [ -n "${ver}" ]; do
		x=$(printf "%c" "${ver}")
		case "${x}" in
			[0-9]) this="digit";;
			-|.|_) this="sep";;
			*)     this="alpha";;
		esac
		if ${dosep} || [ "${this}" != "sep" ]; then
			[ -n "${last}" -a "${this}" != "${last}" ] && printf " "
			printf "%c" "${x}"
		fi
		last=${this}
		ver=${ver#${x}}
	done
}

# Split up a version string into its component parts. If no parameter is
# supplied, defaults to $PV.
#     0.8.3       ->  0 . 8 . 3
#     7c          ->  7 c
#     3.0_p2      ->  3 . 0 _ p2
#     20040905    ->  20040905
#     3.0c-r1     ->  3 . 0 c - r1
get_all_version_components() {
	_get_all_version_components true "$@"
}

# Get the important version components, excluding '.', '-' and '_'. Defaults to
# $PV if no parameter is supplied.
#     0.8.3       ->  0 8 3
#     7c          ->  7 c
#     3.0_p2      ->  3 0 p2
#     20040905    ->  20040905
#     3.0c-r1     ->  3 0 c r1
get_version_components() {
	_get_all_version_components false "$@"
}

# Get the major version of a value. Defaults to $PV if no parameter is supplied.
#     0.8.3       ->  0
#     7c          ->  7
#     3.0_p2      ->  3
#     20040905    ->  20040905
#     3.0c-r1     ->  3
get_major_version() {
	set -- $(get_version_components "$@")
	printf "%s" "$1"
}

# Get everything after the major version and its separator (if present) of a
# value. Defaults to $PV if no parameter is supplied.
#     0.8.3       ->  8.3
#     7c          ->  c
#     3.0_p2      ->  0_p2
#     20040905    ->  (empty string)
#     3.0c-r1     ->  0c-r1
get_after_major_version() {
	printf "%s" "${@#$(get_major_version "$@")}"
}

_replace_version_separator_n() {
	local n=$1 sep=$2 i=0

	set -- $(get_all_version_components "$3")
	while [ -n "$1" ]; do
		case "$1" in
			-|.|_)
				i=$((${i} + 1))
				if [ "${i}" = "${n}" ]; then
					printf "%s" "${sep}"
				else
					printf "%s" "$1"
				fi
				;;
			*)
				printf "%s" "$1"
				;;
		esac
		shift
	done
}

_replace_version_separator_a() {
	local n=$1 sep=$2 i=0

	set -- $(get_all_version_components "$3")
	while [ -n "$1" ]; do
		if [ "${n}" = "$1" ]; then
			printf "%s" "${sep}"
			n=
		else
			printf "%s" "$1"
		fi
		shift
	done
}

# Replace the $1th separator with $2 in $3 (defaults to $PV if $3 is not
# supplied). If there are fewer than $1 separators, don't change anything.
#     1 '_' 1.2.3       -> 1_2.3
#     2 '_' 1.2.3       -> 1.2_3
#     1 '_' 1b-2.3      -> 1b_2.3
# Rather than being a number, $1 can be a separator character such as '-', '.'
# or '_'. In this case, the first separator of this kind is selected.
replace_version_separator() {
	case "$1" in
		[0-9]*) _replace_version_separator_n "$@";;
		*)      _replace_version_separator_a "$@";;
	esac
}

# Replace all version separators in $2 (defaults to $PV) with $1.
#     '_' 1b.2.3        -> 1b_2_3
replace_all_version_separators() {
	local sep=$1

	set -- $(get_all_version_components "$2")
	while [ -n "$1" ]; do
		case "$1" in
			-|.|_) printf "%s" "${sep}";;
			*)     printf "%s" "$1";;
		esac
		shift
	done
}

# Delete the $1th separator in $2 (defaults to $PV if $2 is not supplied). If
# there are fewer than $1 separators, don't change anything.
#     1 1.2.3       -> 12.3
#     2 1.2.3       -> 1.23
#     1 1b-2.3      -> 1b2.3
# Rather than being a number, $1 can be a separator character such as '-', '.'
# or '_'. In this case, the first separator of this kind is deleted.
delete_version_separator() {
	replace_version_separator "$1" "" "$2"
}

# Delete all version separators in $1 (defaults to $PV).
#     1b.2.3        -> 1b23
delete_all_version_separators() {
	replace_all_version_separators "" "$@"
}

# How many version components are there in $1 (defaults to $PV)?
#     1.0.1       ->  3
#     3.0c-r1     ->  4
get_version_component_count() {
	set -- $(get_version_components "$@")
	printf "%s" "$#"
}

# Get a particular component or range of components from the version. If no
# version parameter is supplied, defaults to $PV.
#    1      1.2.3       -> 1
#    1-2    1.2.3       -> 1.2
#    2-     1.2.3       -> 2.3
get_version_component_range() {
	[ -z "$1" ] && return 1

	local range="$(get_all_version_components "$1")"
	shift
	local vers="$(get_all_version_components "$@")"

	set -- ${range}
	local one=$1 two=$2 three=$3

	set -- ${vers}
	local i=1
	while [ ${i} -lt ${one} ]; do
		shift; shift
		i=$((${i} + 1))
	done

	printf "%s" "$1"
	[ "${two}" != "-" ] && return
	shift

	[ -z "${three}" ] && three=$(get_version_component_count "${vers}")
	while [ ${i} -lt ${three} ]; do
		printf "%s" "$1$2"
		shift; shift
		i=$((${i} + 1))
	done
}

_version_getn() {
	local v=$1
	case "$1" in
		0*)    v=${1##*0}; v=${v:-0};;
		-|.|_) v=0;;
	esac
	printf "%s" "${v}"
}

_version_is_prefix() {
	case "$1" in
		alpha|beta|pre|rc) return 0;;
	esac
	return 1
}

# Takes two parameters (a, b) which are versions. If a is an earlier version
# than b, returns 1. If a is identical to b, return 2. If b is later than a,
# return 3. You probably want version_is_at_least rather than this function.
# May not be very reliable. Test carefully before using this.
version_compare() {
	# Don't beat around the bush
	[ "$1" = "$2" ] && return 2

	local ver1="$(get_all_version_components "$1")" ver11= ver11n=
	local ver2="$(get_all_version_components "$2")" ver21= ver21n=

	while [ -n "${ver1}" -o -n "${ver2}" ]; do
		# Grab the components and trim leading 0's
		set -- ${ver1}
		ver11=$(_version_getn "$@")
		[ -n "$1" ] && shift
		ver1="$@"
		set -- ${ver2}
		ver21=$(_version_getn "$@")
		[ -n "$1" ] && shift
		ver2="$@"

		if _version_is_prefix "${ver11}"; then
			_version_is_prefix "${ver21}" || return 1
		else
			_version_is_prefix "${ver21}" && return 3
		fi

		[ -z "${ver11}" ] && ver11=0
		[ -z "${ver21}" ] && ver21=0

		[ "${ver11}" = "${ver21}" ] && continue

		case "${ver11}" in
			[0-9]*) ver11n=true;;
			*)      ver11n=false;;
		esac

		case "${ver21}" in
			[0-9]*) ver21n=true;;
			*)      ver21n=false;;
		esac

		if ${ver11n} && ${ver21n}; then
			# Both are numbers
			[ "${ver11}" -lt "${ver21}" ] && return 1 
			[ "${ver11}" -gt "${ver21}" ] && return 3
		fi

		# Either is not a number, so lexical comparison
		[ "${ver11}" "<" "${ver21}" ] && return 1 
		[ "${ver11}" ">" "${ver21}" ] && return 3
	done

	# All equal then
	return 2 
}

# Is $2 (defaults to $PVR) at least version $1? Intended for use in eclasses
# only. May not be reliable, be sure to do very careful testing before actually
# using this. Prod ciaranm if you find something it can't handle.
version_is_at_least() {
	version_compare "$1" "${2:-${PVR}}"
	case $? in
		1|2) return 0;;
		3)   return 1;;
		*)   die "versionator compare bug";;
	esac
}

# Returns its parameters sorted, highest version last.
version_sort() {
	local sorted= left="$@" item=

	while [ -n "${left}" ]; do
		set -- ${left}
		item=$1
		shift
		left="$@"

		set -- ${sorted}
		sorted=
		local inserted=false
		while [ -n "$1" ]; do
			version_compare "${item}" "$1"
			if [ "$?" = "1" ]; then
				sorted="${sorted}${sorted:+ }${item} $*"
				continue 2
			fi
			sorted="${sorted}${sorted:+ }$1"
			shift
		done

		sorted="${sorted}${sorted:+ }${item}"
	done

	printf "%s" "${sorted}"
}

__versionator__test_version_compare() {
	local lt=1 eq=2 gt=3 p= q=

	__versionator__test_version_compare_t() {
		version_compare "$1" "$3"
		local r=$?
		[ "${r}" != "$2" ] && echo "FAIL: ${@} (got ${r} exp $2)"
	}

	echo "
		0             $lt 1
		1             $lt 2
		2             $gt 1
		2             $eq 2
		0             $eq 0
		10            $lt 20
		68            $eq 068
		068           $gt 67
		068           $lt 69

		1.0           $lt 2.0
		2.0           $eq 2.0
		2.0           $gt 1.0

		1.0           $gt 0.0
		0.0           $eq 0.0
		0.0           $lt 1.0

		0.1           $lt 0.2
		0.2           $eq 0.2
		0.3           $gt 0.2

		1.2           $lt 2.1
		2.1           $gt 1.2

		1.2.3         $lt 1.2.4
		1.2.4         $gt 1.2.3

		1.2.0         $eq 1.2
		1.2.1         $gt 1.2
		1.2           $lt 1.2.1

		1.2b          $eq 1.2b
		1.2b          $lt 1.2c
		1.2b          $gt 1.2a
		1.2b          $gt 1.2
		1.2           $lt 1.2a

		1.3           $gt 1.2a
		1.3           $lt 1.3a

		1.0_alpha7    $lt 1.0_beta7
		1.0_beta      $lt 1.0_pre
		1.0_pre5      $lt 1.0_rc2
		1.0_rc2       $lt 1.0

		1.0_p1        $gt 1.0
		1.0_p1-r1     $gt 1.0_p1

		1.0_alpha6-r1 $gt 1.0_alpha6
		1.0_beta6-r1  $gt 1.0_alpha6-r2

		1.0_pre1      $lt 1.0-p1

		1.0p          $gt 1.0_p1
		1.0r          $gt 1.0-r1
		1.6.15        $gt 1.6.10-r2
		1.6.10-r2     $lt 1.6.15

	" | while read a b c ; do
		[ -z "${a}${b}${c}" ] && continue;
		__versionator__test_version_compare_t "${a}" "${b}" "${c}"
	done


	for q in "alpha beta pre rc=${lt};${gt}" "p r=${gt};${lt}" ; do
		for p in ${q%%=*} ; do
			local c=${q##*=}
			local alt=${c%%;*} agt=${c##*;}
			__versionator__test_version_compare_t "1.0" $agt "1.0_${p}"
			__versionator__test_version_compare_t "1.0" $agt "1.0_${p}1"
			__versionator__test_version_compare_t "1.0" $agt "1.0_${p}068"

			__versionator__test_version_compare_t "2.0_${p}"    $alt "2.0"
			__versionator__test_version_compare_t "2.0_${p}1"   $alt "2.0"
			__versionator__test_version_compare_t "2.0_${p}068" $alt "2.0"

			__versionator__test_version_compare_t "1.0_${p}"  $eq "1.0_${p}"
			__versionator__test_version_compare_t "0.0_${p}"  $lt "0.0_${p}1"
			__versionator__test_version_compare_t "666_${p}3" $gt "666_${p}"

			__versionator__test_version_compare_t "1_${p}7"  $lt "1_${p}8"
			__versionator__test_version_compare_t "1_${p}7"  $eq "1_${p}7"
			__versionator__test_version_compare_t "1_${p}7"  $gt "1_${p}6"
			__versionator__test_version_compare_t "1_${p}09" $eq "1_${p}9"
		done
	done

	for p in "-r" "_p" ; do
		__versionator__test_version_compare_t "7.2${p}1" $lt "7.2${p}2"
		__versionator__test_version_compare_t "7.2${p}2" $gt "7.2${p}1"
		__versionator__test_version_compare_t "7.2${p}3" $gt "7.2${p}2"
		__versionator__test_version_compare_t "7.2${p}2" $lt "7.2${p}3"
	done
}


[-- Attachment #3: sh-portable.patch --]
[-- Type: text/x-diff, Size: 600 bytes --]

173c173
< 	local range=$(get_all_version_components "$1")
---
> 	local range="$(get_all_version_components "$1")"
175c175
< 	local vers=$(get_all_version_components "$@")
---
> 	local vers="$(get_all_version_components "$@")"
223,224c223,224
< 	local ver1=$(get_all_version_components "$1") ver11= ver11n=
< 	local ver2=$(get_all_version_components "$2") ver21= ver21n=
---
> 	local ver1="$(get_all_version_components "$1")" ver11= ver11n=
> 	local ver2="$(get_all_version_components "$2")" ver21= ver21n=
230c230
< 		shift
---
> 		[ -n "$1" ] && shift
234c234
< 		shift
---
> 		[ -n "$1" ] && shift

Re: [gentoo-dev] RFC: sh versionator.eclass

[Fernando J. Pereda]

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

On Mon, Oct 01, 2007 at 11:30:16PM +0100, Roy Marples wrote:
> On Monday 01 October 2007 22:59:40 Roy Marples wrote:
> > This version, I believe, is more readable and maintainable then the one
> > currently in portage. It also uses a lot less code and has the bonus of
> > being pure sh.
> 
> It should be noted that that first draft was developed on bash only.
> Attached is a patch that fixes quoting on all shells and shift errors on 
> ash/dash/busybox variants.
> 
> Also attached is the patched versionater.eclass again.
> 
> Thanks
> 

I sure as hell am not going to proof read all that (mainly because I
think not using bash features in an environment where bash is required
is silly, instead of being an improvement) but I find interesting that
you ripped Ciaran's copyright while leaving the "Prod ciaranm if you
find something it can't handle" comment.

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

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

Re: [gentoo-dev] RFC: sh versionator.eclass

[Roy Marples]

On Monday 01 October 2007 23:41:36 Fernando J. Pereda wrote:
> I sure as hell am not going to proof read all that (mainly because I
> think not using bash features in an environment where bash is required
> is silly, instead of being an improvement)

OK. Maybe I shouldn't have mentioned the "in sh" bit.
If I re-submit stuff and just claim better readability and less code you'll 
read it then?

> but I find interesting that 
> you ripped Ciaran's copyright while leaving the "Prod ciaranm if you
> find something it can't handle" comment.

I copied and pasted the comments for the most part. Sorry for leaving that bit 
in. And I thought that the Gentoo Foundation had the copyright?

Thanks

Roy
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Mike Frysinger]

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

On Monday 01 October 2007, Roy Marples wrote:
> On Monday 01 October 2007 23:41:36 Fernando J. Pereda wrote:
> > I sure as hell am not going to proof read all that (mainly because I
> > think not using bash features in an environment where bash is required
> > is silly, instead of being an improvement)
>
> OK. Maybe I shouldn't have mentioned the "in sh" bit.
> If I re-submit stuff and just claim better readability and less code you'll
> read it then?

"better readability" is a pretty subjective claim ... i'd say that changing 
things from doing a case match against proper character classes to doing a 
printf against arbitrary character ranges (which btw are not locale safe, so 
i imagine you've introduced a regression there) is not "better".  but i'm not 
the maintainer of said eclass.

> > but I find interesting that
> > you ripped Ciaran's copyright while leaving the "Prod ciaranm if you
> > find something it can't handle" comment.
>
> I copied and pasted the comments for the most part. Sorry for leaving that
> bit in. And I thought that the Gentoo Foundation had the copyright?

it does.  and if it doesnt, punt the file and rewrite it from scratch.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] RFC: sh versionator.eclass

[Roy Marples]

On Mon, 2007-10-01 at 20:22 -0400, Mike Frysinger wrote:
> "better readability" is a pretty subjective claim ...

Many things are subjective - one mans good is another mans bad.
/me shrugs

>  i'd say that changing 
> things from doing a case match against proper character classes to doing a 
> printf against arbitrary character ranges (which btw are not locale safe, so 
> i imagine you've introduced a regression there) is not "better".  but i'm not 
> the maintainer of said eclass.

That is why the case match is like so

[0-9]      Should be safe - every language should operate in base 10
-|.|_      Exact match
*          If it's not the above, treat it like a letter

So there shouldn't be any regressions with version numbers here as I've
cunningly avoided the locale trap.

> > > but I find interesting that
> > > you ripped Ciaran's copyright while leaving the "Prod ciaranm if you
> > > find something it can't handle" comment.
> >
> > I copied and pasted the comments for the most part. Sorry for leaving that
> > bit in. And I thought that the Gentoo Foundation had the copyright?
> 
> it does.  and if it doesnt, punt the file and rewrite it from scratch.

Well, this should constitute a rewrite from scratch.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: RFC: sh versionator.eclass

[Duncan]

Roy Marples <uberlord@gentoo.org> posted
1191306400.63509.4.camel@uberlaptop.marples.name, excerpted below, on 
Tue, 02 Oct 2007 07:26:39 +0100:

>> > > but I find interesting that
>> > > you ripped Ciaran's copyright while leaving the "Prod ciaranm if
>> > > you find something it can't handle" comment.
>> >
>> > I copied and pasted the comments for the most part. Sorry for leaving
>> > that bit in. And I thought that the Gentoo Foundation had the
>> > copyright?
>> 
>> it does.  and if it doesnt, punt the file and rewrite it from scratch.
> 
> Well, this should constitute a rewrite from scratch.

That's good, because IIRC, Ciaranm has stated before that he did /not/
sign the copyright hand-over -- it wasn't required by the time he
came around, so if I'm not mistaken, particularly since that's what the 
original claimed, that /would/ be copyright Ciaran.  However, a rewrite 
should take care of it, so as I said, good, if you're planning on 
reassigning.  I'd still consider putting in a "based on ..." crediting 
him, as only polite, but I don't know that it's necessary.

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

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Mike Frysinger]

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

On Tuesday 02 October 2007, Roy Marples wrote:
> On Mon, 2007-10-01 at 20:22 -0400, Mike Frysinger wrote:
> >  i'd say that changing
> > things from doing a case match against proper character classes to doing
> > a printf against arbitrary character ranges (which btw are not locale
> > safe, so i imagine you've introduced a regression there) is not "better".
> >  but i'm not the maintainer of said eclass.
>
> That is why the case match is like so
>
> [0-9]      Should be safe - every language should operate in base 10
> -|.|_      Exact match
> *          If it's not the above, treat it like a letter
>
> So there shouldn't be any regressions with version numbers here as I've
> cunningly avoided the locale trap.

sorry, you're right ... i thought i saw a [A-Z] in there, but it was probably 
that the old one used [:alpha:]

that said, there's no reason to change [[:digit:]] to [0-9] ... using proper 
character classes is preferred over custom rangers regardless
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] RFC: sh versionator.eclass

[Natanael Copa]

On Mon, 2007-10-01 at 23:30 +0100, Roy Marples wrote:
> On Monday 01 October 2007 22:59:40 Roy Marples wrote:
> > This version, I believe, is more readable and maintainable then the one
> > currently in portage. It also uses a lot less code and has the bonus of
> > being pure sh.
> 
> It should be noted that that first draft was developed on bash only.
> Attached is a patch that fixes quoting on all shells and shift errors on 
> ash/dash/busybox variants.

Reuseable code. Great!

> Also attached is the patched versionater.eclass again.

After a quick look I wonder how/if it deals with:

1.01 < 1.1

-nc


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Roy Marples]

On Tue, 2007-10-02 at 08:35 +0200, Natanael Copa wrote:
> After a quick look I wonder how/if it deals with:
> 
> 1.01 < 1.1

It treats them the same way

roy@uberlaptop ~ $ bash -c '. /usr/portage/eclass/versionator.eclass;
version_compare 1.01 1.1; echo $?'
2
roy@uberlaptop ~ $ bash -c '. ./versionator.eclass; version_compare 1.01
1.1; echo $?'
2

I'm also glad you asked as spb claims my version is broken with repsect
to this. I disagree as it matches the portage version.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: RFC: sh versionator.eclass

[Steve Long]

Roy Marples wrote:

> On Tue, 2007-10-02 at 08:35 +0200, Natanael Copa wrote:
>> After a quick look I wonder how/if it deals with:
>> 
>> 1.01 < 1.1
> 
> It treats them the same way
> 
> roy@uberlaptop ~ $ bash -c '. /usr/portage/eclass/versionator.eclass;
> version_compare 1.01 1.1; echo $?'
> 2
> roy@uberlaptop ~ $ bash -c '. ./versionator.eclass; version_compare 1.01
> 1.1; echo $?'
> 2
> 
> I'm also glad you asked as spb claims my version is broken with repsect
> to this. I disagree as it matches the portage version.
> 
My understanding of how portage deals with this is that, since one of the
components begins with 0, a `floating-point' comparison is used. IOW 1.10 >
1.01 and they are not the same at all.

I am pretty sure this is how it works, as we had to do a verCompare for
update (consistency check for depclean originally) and looked at the
portage code as well as the bash interrev code for prefix(?) portage,
before coming up with our own version in bash[1] based on the spec. We
particularly wanted to shortcut stuff and not use any externals iirc (it
was a while ago.)
The test script is used with eg:
./verCmp 1.01 1.1
./verCmp older 1.1-r3 1.1-r2
./verCmp newer 1.1a_alpha20070822-r1 1.1_alpha20070822-r1

It does handles interrevs for comparison, but doesn't yet provide
the "distance" which is needed for prefix portage. It's enough for our
purposes in update, where we simply need to know whether the two are equal,
or if a is older or newer than b.

[1] http://phpfi.com/266380 -- there was a small bug in the one we pasted
before in #gentoo-portage, which had been corrected in update. (Please
don't have a go at me about GPL3-- it's not my call, and Gentoo can use it
under GPL2, should you ever want to.) Bug-reports welcomed :)


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Fabian Groffen]

On 01-10-2007 22:59:40 +0100, Roy Marples wrote:
> I would like to propse a new versionator.eclass for consideration (attached).
> 
> This version, I believe, is more readable and maintainable then the one 
> currently in portage. It also uses a lot less code and has the bonus of being 
> pure sh.

What is your rationale to say that "pure sh" is a "bonus"?  Especially
given the environment this is used in as ferdy already pointed out?

I personally like consistency.  So if we use bash in ebuilds, then I'd
like to use bash in eclasses too.  I'm interested in your motivation to
make this eclass "pure sh", whatever that may mean.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Roy Marples]

On Tue, 2007-10-02 at 09:29 +0200, Fabian Groffen wrote:
> On 01-10-2007 22:59:40 +0100, Roy Marples wrote:
> > I would like to propse a new versionator.eclass for consideration (attached).
> > 
> > This version, I believe, is more readable and maintainable then the one 
> > currently in portage. It also uses a lot less code and has the bonus of being 
> > pure sh.
> 
> What is your rationale to say that "pure sh" is a "bonus"?  Especially
> given the environment this is used in as ferdy already pointed out?

The bonus is that it works on shells other than bash.

> I personally like consistency.  So if we use bash in ebuilds, then I'd
> like to use bash in eclasses too.  I'm interested in your motivation to
> make this eclass "pure sh", whatever that may mean.

I like consistency too, and I'll be pushing for using sh instead of
forcing bash.

My motivation? Simple. I don't believe that the portage tree should be
locked into using one shell. I believe that vendor lock-in should happen
at the social level, not the technical one. portage itself was a lock-in
until until PMS came about, now I'd like to remove the lock-in from the
tree itself. This in itself is a good thing as we can pick and choose
the tools we want to use as they're all playing on the same field.

This same rationale applies to scriptlets outside portage tree use, such
as revdep-rebuild [1]. It's more of a bashlet, but I've also
demonstrated that there was no reason to force bash there.

Obviously there are more lock-ins than just the shell, but it's a good
start.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Fabian Groffen]

On 02-10-2007 09:48:06 +0100, Roy Marples wrote:
> > What is your rationale to say that "pure sh" is a "bonus"?  Especially
> > given the environment this is used in as ferdy already pointed out?
> 
> The bonus is that it works on shells other than bash.

I give you a big chance Solaris' or AIX' /bin/sh won't grok this stuff.

> > I personally like consistency.  So if we use bash in ebuilds, then I'd
> > like to use bash in eclasses too.  I'm interested in your motivation to
> > make this eclass "pure sh", whatever that may mean.
> 
> I like consistency too, and I'll be pushing for using sh instead of
> forcing bash.

I admire your courage.

> My motivation? Simple. I don't believe that the portage tree should be
> locked into using one shell. I believe that vendor lock-in should happen

"vendor lock-in" is an interesting term to mention here, as bash is open
source, and I think (I'm not a lawyer) free to use as long as you want,
and modifyable if you like.

> at the social level, not the technical one. portage itself was a lock-in
> until until PMS came about, now I'd like to remove the lock-in from the
> tree itself. This in itself is a good thing as we can pick and choose
> the tools we want to use as they're all playing on the same field.
>
> This same rationale applies to scriptlets outside portage tree use, such
> as revdep-rebuild [1]. It's more of a bashlet, but I've also
> demonstrated that there was no reason to force bash there.
> 
> Obviously there are more lock-ins than just the shell, but it's a good
> start.

Given my own "history" I have a hard time to believe you are persuing
the right track here.  It may or may not be a secret that I currently do
the complete opposite of what you're trying to do -- so far with a good
lot of success, especially given the number of completely different
platforms.

Question from me to you is, whether your vision is just to get (Free)BSD
working seamlessly with Gentoo, or whether you also look beyond your
current scope to the "Meta Distribution".  This includes the benefit of
moving from bash to POSIX(?) sh as standard kit to interpret the meta
information.  Changing init.d scripts is one thing, changing the
definition of how the meta information should be read is another thing.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Roy Marples]

On Tue, 2007-10-02 at 11:22 +0200, Fabian Groffen wrote:
> On 02-10-2007 09:48:06 +0100, Roy Marples wrote:
> > > What is your rationale to say that "pure sh" is a "bonus"?  Especially
> > > given the environment this is used in as ferdy already pointed out?
> > 
> > The bonus is that it works on shells other than bash.
> 
> I give you a big chance Solaris' or AIX' /bin/sh won't grok this stuff.

Neither claim to be posix shells either, or didn't last I looked.
I say baselayout-2 works with any shell that claims posix. Of course,
changing it to bash is a trivial matter also.

> > My motivation? Simple. I don't believe that the portage tree should be
> > locked into using one shell. I believe that vendor lock-in should happen
> 
> "vendor lock-in" is an interesting term to mention here, as bash is open
> source, and I think (I'm not a lawyer) free to use as long as you want,
> and modifyable if you like.

Just because it's open source does not mean that it won't try and lock
you in.

> Given my own "history" I have a hard time to believe you are persuing
> the right track here.  It may or may not be a secret that I currently do
> the complete opposite of what you're trying to do -- so far with a good
> lot of success, especially given the number of completely different
> platforms.
> 
> Question from me to you is, whether your vision is just to get (Free)BSD
> working seamlessly with Gentoo, or whether you also look beyond your
> current scope to the "Meta Distribution".  This includes the benefit of
> moving from bash to POSIX(?) sh as standard kit to interpret the meta
> information.  Changing init.d scripts is one thing, changing the
> definition of how the meta information should be read is another thing.

A common parlance on Slashdot when referring to Microsoft is that
monoculture is bad. Forcing bash and GNU tools down everyones throat is
no better - it's just replacing one monoculture with another one.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Fabian Groffen]

On 02-10-2007 10:37:25 +0100, Roy Marples wrote:
> > "vendor lock-in" is an interesting term to mention here, as bash is open
> > source, and I think (I'm not a lawyer) free to use as long as you want,
> > and modifyable if you like.
> 
> Just because it's open source does not mean that it won't try and lock
> you in.

as far as I'm aware it can't lock you in as in the original definition
of the term "lock-in", but I get your point, even though I disagree.

> > Question from me to you is, whether your vision is just to get (Free)BSD
> > working seamlessly with Gentoo, or whether you also look beyond your
> > current scope to the "Meta Distribution".  This includes the benefit of
> > moving from bash to POSIX(?) sh as standard kit to interpret the meta
> > information.  Changing init.d scripts is one thing, changing the
> > definition of how the meta information should be read is another thing.
> 
> A common parlance on Slashdot when referring to Microsoft is that
> monoculture is bad. Forcing bash and GNU tools down everyones throat is
> no better - it's just replacing one monoculture with another one.

Which doesn't seem to be an answer to the question at all to me.  My
question was basically about what the benefits are of changing the meta
information interpretation definition.  In other words, if project X
says their code should be compiled with GCC, what are the benefits
exactly if you change that into "should be compiled with a C99 compliant
compiler", considering you are eventually interested in the produced
code only.  (Is it worth it to teach/force devs to use something else
if this is only how to obtain the end product, which should run with
"anything"?)


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Roy Marples]

On Tue, 2007-10-02 at 11:49 +0200, Fabian Groffen wrote:
> Which doesn't seem to be an answer to the question at all to me.  My
> question was basically about what the benefits are of changing the meta
> information interpretation definition.  In other words, if project X
> says their code should be compiled with GCC, what are the benefits
> exactly if you change that into "should be compiled with a C99 compliant
> compiler", considering you are eventually interested in the produced
> code only.  (Is it worth it to teach/force devs to use something else
> if this is only how to obtain the end product, which should run with
> "anything"?)

project X says their code should be compiled with GCC, should we deny
the ICC users the ability to compile it? I don't think so. I think users
should have a choice. If users didn't have choice, then EGCS would never
have happened.

I believe it is work teaching devs to use POSIX shell over bash. For
example, many of the recent commits have highlighted that a lot of devs
have no idea when it comes to quoting. My view on this is because bash
encourages you not to quote by using [[ ]], unlike POSIX [ ] which
forces you to know when to quote.

It also means that their code stands a better chance of working where
bash is not available, but /bin/sh is a POSIX shell still.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Mike Frysinger]

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

On Tuesday 02 October 2007, Roy Marples wrote:
> On Tue, 2007-10-02 at 11:49 +0200, Fabian Groffen wrote:
> > Which doesn't seem to be an answer to the question at all to me.  My
> > question was basically about what the benefits are of changing the meta
> > information interpretation definition.  In other words, if project X
> > says their code should be compiled with GCC, what are the benefits
> > exactly if you change that into "should be compiled with a C99 compliant
> > compiler", considering you are eventually interested in the produced
> > code only.  (Is it worth it to teach/force devs to use something else
> > if this is only how to obtain the end product, which should run with
> > "anything"?)
>
> project X says their code should be compiled with GCC, should we deny
> the ICC users the ability to compile it?

that is project X's decision and no one else's.  dont pull a stallman on us 
and force everyone to subscribe to your ideas of "freedom".  there's a reason 
we told him to take a hike.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] RFC: sh versionator.eclass

[Roy Marples]

On Tue, 2007-10-02 at 06:28 -0400, Mike Frysinger wrote:
> > project X says their code should be compiled with GCC, should we deny
> > the ICC users the ability to compile it?
> 
> that is project X's decision and no one else's.  dont pull a stallman on us 
> and force everyone to subscribe to your ideas of "freedom".  there's a reason 
> we told him to take a hike.

We change upstream decisions all the time via patches and USE flags when
we as developers think that it could be done better, to make it fit into
our file layout.

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Mike Frysinger]

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

On Tuesday 02 October 2007, Roy Marples wrote:
> On Tue, 2007-10-02 at 06:28 -0400, Mike Frysinger wrote:
> > > project X says their code should be compiled with GCC, should we deny
> > > the ICC users the ability to compile it?
> >
> > that is project X's decision and no one else's.  dont pull a stallman on
> > us and force everyone to subscribe to your ideas of "freedom".  there's a
> > reason we told him to take a hike.
>
> We change upstream decisions all the time via patches and USE flags when
> we as developers think that it could be done better, to make it fit into
> our file layout.

some people (because it's in *their* interest to do so) have the option of 
maintaining changes.  that does not mean anyone is required to do so.  glibc 
for example provides no support unless you build it with gcc.  so how does 
icc build it ?  they implement the *useful* GNU extensions.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] RFC: sh versionator.eclass

[Fabian Groffen]

On 02-10-2007 11:09:21 +0100, Roy Marples wrote:
> It also means that their code stands a better chance of working where
> bash is not available, but /bin/sh is a POSIX shell still.

I prefer to define that ebuilds (and eclasses) are dealt by GNU bash,
which is installed as part of the installation ritual for a Gentoo/X
system.  I also prefer to define that all common tools ebuilds and
eclasses use such as cp, rm, awk, sed, find, xargs are GNU variants,
installed as part of the same installation ritual for a Gentoo/X system.
With such "definition", a Gentoo/X system without bash cannot exist.

What you use outside of the Gentoo build/package manager environment is
completely up to you.


Rationale:
All tools (bash, coreutils, findutils, sed, gawk) can be compiled and
installed on any system I know of.  Their use is widespread and
accepted.  Our primary group of people working on ebuilds and eclasses
(Gentoo developers) work on a Gentoo system having said tools (and only
those) installed, making it a logical choice.


I personally fail to see the advantage of using "portable" or "standards
compliant" code here over what we have currently.  We don't force it
down on anyone, we only use it to install a package for you.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Roy Marples]

On Tue, 2007-10-02 at 12:41 +0200, Fabian Groffen wrote:
> On 02-10-2007 11:09:21 +0100, Roy Marples wrote:
> > It also means that their code stands a better chance of working where
> > bash is not available, but /bin/sh is a POSIX shell still.
> 
> I prefer to define that ebuilds (and eclasses) are dealt by GNU bash,
> which is installed as part of the installation ritual for a Gentoo/X
> system.  I also prefer to define that all common tools ebuilds and
> eclasses use such as cp, rm, awk, sed, find, xargs are GNU variants,
> installed as part of the same installation ritual for a Gentoo/X system.
> With such "definition", a Gentoo/X system without bash cannot exist.
> 
> What you use outside of the Gentoo build/package manager environment is
> completely up to you.

In other words, regardless of shell being used, you have to know that in
an ebuild sed, awk, rm, cp, find et all are really GNU sed.
Lets not beat around the bush here! Why not just use gsed in an ebuild
and be clear about it?

> 
> 
> Rationale:
> All tools (bash, coreutils, findutils, sed, gawk) can be compiled and
> installed on any system I know of.  Their use is widespread and
> accepted.  Our primary group of people working on ebuilds and eclasses
> (Gentoo developers) work on a Gentoo system having said tools (and only
> those) installed, making it a logical choice.
> 
> 
> I personally fail to see the advantage of using "portable" or "standards
> compliant" code here over what we have currently.  We don't force it
> down on anyone, we only use it to install a package for you.

Using that rationale, scrap the kernel and system libs too and just
install GNU/Linux with GNU/glibc

Infact, if we're not interested in portable code why bother with
Gentoo/ALT in the first place?

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Fabian Groffen]

On 02-10-2007 12:00:12 +0100, Roy Marples wrote:
> Infact, if we're not interested in portable code why bother with
> Gentoo/ALT in the first place?

Our code /IS/ portable, that's why you and me have a working Gentoo/Alt
system at the moment.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Mike Frysinger]

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

On Tuesday 02 October 2007, Roy Marples wrote:
> A common parlance on Slashdot when referring to Microsoft is that
> monoculture is bad. Forcing bash and GNU tools down everyones throat is
> no better - it's just replacing one monoculture with another one.

wrong.  bash and GNU prevail because they provide useful extensions.  it may 
be worthwhile to force `find` in the portage environment to be GNU find so we 
can stop wasting time trying to figure out how to rewrite expressions in 
ebuilds (which can be done trivially with GNU) with a limited functionality 
set (such as POSIX).

i may also point out that many GNU extensions get codified in POSIX over 
time ... why ?  because *they are useful*.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] RFC: sh versionator.eclass

[Roy Marples]

On Tue, 2007-10-02 at 06:10 -0400, Mike Frysinger wrote:
> On Tuesday 02 October 2007, Roy Marples wrote:
> > A common parlance on Slashdot when referring to Microsoft is that
> > monoculture is bad. Forcing bash and GNU tools down everyones throat is
> > no better - it's just replacing one monoculture with another one.
> 
> wrong.  bash and GNU prevail because they provide useful extensions.  it may 
> be worthwhile to force `find` in the portage environment to be GNU find so we 
> can stop wasting time trying to figure out how to rewrite expressions in 
> ebuilds (which can be done trivially with GNU) with a limited functionality 
> set (such as POSIX).

BSD find also has the similar extensions, just implemented differently.

> 
> i may also point out that many GNU extensions get codified in POSIX over 
> time ... why ?  because *they are useful*.

By the same token I should be able to use BSD extensions if said program
also works on Linux. Also, BSD extensions get codified in POSIX also. My
understanding is that a lot of POSIX is based on BSD4.

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Mike Frysinger]

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

On Tuesday 02 October 2007, Roy Marples wrote:
> On Tue, 2007-10-02 at 06:10 -0400, Mike Frysinger wrote:
> > On Tuesday 02 October 2007, Roy Marples wrote:
> > > A common parlance on Slashdot when referring to Microsoft is that
> > > monoculture is bad. Forcing bash and GNU tools down everyones throat is
> > > no better - it's just replacing one monoculture with another one.
> >
> > wrong.  bash and GNU prevail because they provide useful extensions.  it
> > may be worthwhile to force `find` in the portage environment to be GNU
> > find so we can stop wasting time trying to figure out how to rewrite
> > expressions in ebuilds (which can be done trivially with GNU) with a
> > limited functionality set (such as POSIX).
>
> BSD find also has the similar extensions, just implemented differently.
>
> > i may also point out that many GNU extensions get codified in POSIX over
> > time ... why ?  because *they are useful*.
>
> By the same token I should be able to use BSD extensions if said program
> also works on Linux. Also, BSD extensions get codified in POSIX also. My
> understanding is that a lot of POSIX is based on BSD4.

BSD is a second class citizen to GNU here.  Gentoo started out as a project 
targetting a GNU userland under Linux and will continue for quite sometime 
(forever?) as the majority/core focus.  forcing the project to limit itself 
when there is no gain (yet plenty of pain) for the majority of users is a no 
brainer: no.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] RFC: sh versionator.eclass

[Roy Marples]

On Tue, 2007-10-02 at 06:49 -0400, Mike Frysinger wrote:
> BSD is a second class citizen to GNU here.  Gentoo started out as a project 
> targetting a GNU userland under Linux and will continue for quite sometime 
> (forever?) as the majority/core focus.  forcing the project to limit itself 
> when there is no gain (yet plenty of pain) for the majority of users is a no 
> brainer: no.

Well, let me be the first to stand for equal rights then!

Anyway, this was about changing the portage tree syntax from bash to
posix shell, not gnu vs bsd vs userland tools. The arguments are not the
same as bash supports posix shell whereas gnu tools don't support bsd
extensions and bsd tools don't support gnu extensions.

I say that for the most part, there should be no technical reason why
ebuilds cannot be in posix shell whilst being readable and maintainable.

If portage or another package manager wishes to uses bash to parse
ebuilds and eclasses, more power to them! I won't stop that. I just want
the ability for other shells to do the same. It isn't hard, and you
don't need to be a rocket scientist. It's not an overnight change, but a
gradual change.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Luca Barbato]

Roy Marples wrote:
> Well, let me be the first to stand for equal rights then!

Hm...

> 
> I say that for the most part, there should be no technical reason why
> ebuilds cannot be in posix shell whilst being readable and maintainable.

Beside teaching us how to do that.

> If portage or another package manager wishes to uses bash to parse
> ebuilds and eclasses, more power to them! I won't stop that. I just want
> the ability for other shells to do the same. It isn't hard, and you
> don't need to be a rocket scientist. It's not an overnight change, but a
> gradual change.

I'm more radical, what if I want to have my package manager parse
ebuilds w/out needing outside shell but a custom tailed parser (because
of performance)? Nothing prevents to implement the parser from scratch
in both cases...

IFF your proposed changes lead to something that is simpler or as simple
to write, faster or as fast to parse, easier or as easy to
read/maintain; then you may have a solid stance. Otherwise it is a
pointless annoyance for everybody, you first, us second.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Mike Frysinger]

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

On Tuesday 02 October 2007, Luca Barbato wrote:
> IFF your proposed changes lead to something that is simpler or as simple
> to write, faster or as fast to parse, easier or as easy to
> read/maintain; then you may have a solid stance. Otherwise it is a
> pointless annoyance for everybody, you first, us second.

in the general case, dash will typically parse faster than bash.  but is this 
speed gain relevant ?  if dash can parse an ebuild in 10% of the time that it 
takes bash, but bash can do it in a 1 second, do we care ?  the majority of 
ebuilds are going to take magnitudes larger to get the job done 
(running ./configure && make).
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] RFC: sh versionator.eclass

[Luca Barbato]

Mike Frysinger wrote:
> in the general case, dash will typically parse faster than bash.  but is this 
> speed gain relevant ?  if dash can parse an ebuild in 10% of the time that it 
> takes bash, but bash can do it in a 1 second, do we care ?  the majority of 
> ebuilds are going to take magnitudes larger to get the job done 
> (running ./configure && make).

You may want to parse an ebuild not just for building it ^^

still my point is that if the alternative isn't better isn't interesting =/

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Mike Frysinger]

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

On Tuesday 02 October 2007, Luca Barbato wrote:
> Mike Frysinger wrote:
> > in the general case, dash will typically parse faster than bash.  but is
> > this speed gain relevant ?  if dash can parse an ebuild in 10% of the
> > time that it takes bash, but bash can do it in a 1 second, do we care ? 
> > the majority of ebuilds are going to take magnitudes larger to get the
> > job done
> > (running ./configure && make).
>
> You may want to parse an ebuild not just for building it ^^

true ... but i'd have to wonder if there's anything worth parsing out that the 
pregenerated metadata does not provide for you ... i guess if you want to 
parse an ebuild that isnt in the tree thus lacks metadata ... but we further 
marginalize the use ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] RFC: sh versionator.eclass

[Natanael Copa]

On Tue, 2007-10-02 at 09:26 -0400, Mike Frysinger wrote:
> On Tuesday 02 October 2007, Luca Barbato wrote:
> > Mike Frysinger wrote:
> > > in the general case, dash will typically parse faster than bash.  but is
> > > this speed gain relevant ?  if dash can parse an ebuild in 10% of the
> > > time that it takes bash, but bash can do it in a 1 second, do we care ? 
> > > the majority of ebuilds are going to take magnitudes larger to get the
> > > job done
> > > (running ./configure && make).
> >
> > You may want to parse an ebuild not just for building it ^^
> 
> true ... but i'd have to wonder if there's anything worth parsing out that the 
> pregenerated metadata does not provide for you ...

pkg_* and stuff that binary package managers needs. Things that creates
user accounts etc.

I would actually prefer getting that stuff into metadata. It would open
up new doors for binary only package managers.

>  i guess if you want to 
> parse an ebuild that isnt in the tree thus lacks metadata ... but we further 
> marginalize the use ...
> -mike

-nc

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Mike Frysinger]

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

On Tuesday 02 October 2007, Roy Marples wrote:
> On Tue, 2007-10-02 at 06:49 -0400, Mike Frysinger wrote:
> > BSD is a second class citizen to GNU here.  Gentoo started out as a
> > project targetting a GNU userland under Linux and will continue for quite
> > sometime (forever?) as the majority/core focus.  forcing the project to
> > limit itself when there is no gain (yet plenty of pain) for the majority
> > of users is a no brainer: no.
>
> Well, let me be the first to stand for equal rights then!

equal rights lose when the minority causes undue support burdens on the 
majority, especially when there's simple ways for the minorties to conform.

> Anyway, this was about changing the portage tree syntax from bash to
> posix shell, not gnu vs bsd vs userland tools. The arguments are not the
> same as bash supports posix shell whereas gnu tools don't support bsd
> extensions and bsd tools don't support gnu extensions.

it is the same argument.  you're proposing technically inferior solutions for 
no gain whatsoever to the majority of people.

> I say that for the most part, there should be no technical reason why
> ebuilds cannot be in posix shell whilst being readable and maintainable.

the devils in the details isnt it.  i've already mentioned deficiencies in the 
POSIX syntax when compared to bash which is commonly used.  if the POSIX 
standard cannot satisfy the entire tree, then there's no point in converting 
subsets -- you lead to ugly inconsistencies which can be very confusing for 
people who dont live breathe eat poop eat some more this crap every day 
(which i'd wager is pretty much everyone in Gentoo), nor do i think this 
should be a hard requirement.  you and i and a very small handful of other 
people are irrelevant drops in the Gentoo bucket.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] RFC: sh versionator.eclass

[Alec Warner]

On 10/2/07, Roy Marples <uberlord@gentoo.org> wrote:
> On Tue, 2007-10-02 at 06:49 -0400, Mike Frysinger wrote:
> > BSD is a second class citizen to GNU here.  Gentoo started out as a project
> > targetting a GNU userland under Linux and will continue for quite sometime
> > (forever?) as the majority/core focus.  forcing the project to limit itself
> > when there is no gain (yet plenty of pain) for the majority of users is a no
> > brainer: no.

>
> Well, let me be the first to stand for equal rights then!

So there is a difference I think between 'making stuff work on BSD'
and 'changing the fundamental requirements of the distribution'.

>
> Anyway, this was about changing the portage tree syntax from bash to
> posix shell, not gnu vs bsd vs userland tools. The arguments are not the
> same as bash supports posix shell whereas gnu tools don't support bsd
> extensions and bsd tools don't support gnu extensions.
>
> I say that for the most part, there should be no technical reason why
> ebuilds cannot be in posix shell whilst being readable and maintainable.
>

There is no technical reason.  But if you think for two seconds this
is only a technical problem then I think you have not examined it
properly.  Most of the developers here are running GNU/linux with GNU
tools (as has been pointed out).  These are the tools that are used
and there is no gain *for them* to write in what I can only gather as
an inferior but portable sh syntax.  They would be writing for sh only
to satisfy you, and you have IMHO done a poor job of motivating them.
You can put bash in baselayout in BSD in like 2 seconds and prevent
all this hard work you are asking of other developers.

Personally, I like your idea in general until I have to start writing
ebuilds in sh, and init scripts in sh, and pretty much anything in sh;
as vapier points out, sh sucks donkey balls.  So I *will* use bash,
because the fix is 'gentoo requires bash', it's always required bash,
and you haven't convinced me that it should change.  Unless there is
some crazy ass reason why you can't install bash on a given platform,
I don't think there is a technical reason to avoid using bash.

> If portage or another package manager wishes to uses bash to parse
> ebuilds and eclasses, more power to them! I won't stop that. I just want
> the ability for other shells to do the same. It isn't hard, and you
> don't need to be a rocket scientist. It's not an overnight change, but a
> gradual change.
>
> Thanks
>
> Roy
>
> --
> gentoo-dev@gentoo.org mailing list
>
>
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Natanael Copa]

On Tue, 2007-10-02 at 05:39 -0700, Alec Warner wrote:

> I don't think there is a technical reason to avoid using bash.

Ofcourse there is. See first issue mentioned in BUGS section in bash
manpage.

-nc


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Richard Freeman]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Natanael Copa wrote:
> On Tue, 2007-10-02 at 05:39 -0700, Alec Warner wrote:
> 
>> I don't think there is a technical reason to avoid using bash.
> 
> Ofcourse there is. See first issue mentioned in BUGS section in bash
> manpage.
> 

Presumably these bugs don't impact gentoo or we'd already be working
around them.

I don't see an issue with having bash as a gentoo dependency.  Users
don't have to use it as their primary shell - they just need to have it
installed.

I probably wouldn't use python at all if it weren't for portage, but I'm
not complaining about migrating that.

Now, if there were some gentoo target platform for which bash wasn't
available maybe that would be a different issue - or if we were talking
about some huge package that consumed tons of ram/space/etc.  However,
nobody is going to run gentoo on an embedded system (unless they build
the system and then prune out the toolchain - in which case rm /bin/bash
is pretty simple to do).

Don't get me wrong - I would prefer that gentoo support more choices
more officially (paludis comes to mind).  However, that doesn't mean
that we need to support choices that don't provide significant benefits.

Now, if a posix-clean herd wants to take on the work of retooling stuff
to be posixly-correct then perhaps we might ask other devs to be nice to
them and accommodate their changes.  However, that is a bit different
than asking all the devs to use syntax that perhaps they're less than
familiar with.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHAmVfG4/rWKZmVWkRAnlLAJ4noZkumP5prEofYtRDFyhYruPMIACgj2ZM
lpaA2Ky4AdC3fTyL7AzBmfU=
=qvmS
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 4101 bytes --]

Re: [gentoo-dev] RFC: sh versionator.eclass

[Joe Peterson]

Mike Frysinger wrote:
> wrong.  bash and GNU prevail because they provide useful extensions.  it may 
> be worthwhile to force `find` in the portage environment to be GNU find so we 
> can stop wasting time trying to figure out how to rewrite expressions in 
> ebuilds (which can be done trivially with GNU) with a limited functionality 
> set (such as POSIX).

Shouldn't we do just the opposite?  GNU find doesn't exist on all archs
(BSD is an example).  There was just an example of GNU extensions being
used on find that broke on FreeBSD.  It would be more portable to
*avoid* GNU-only extensions in ebuilds.

					-Joe
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Roy Marples]

On Tue, 2007-10-02 at 17:02 -0600, Joe Peterson wrote:
> Mike Frysinger wrote:
> > wrong.  bash and GNU prevail because they provide useful extensions.  it may 
> > be worthwhile to force `find` in the portage environment to be GNU find so we 
> > can stop wasting time trying to figure out how to rewrite expressions in 
> > ebuilds (which can be done trivially with GNU) with a limited functionality 
> > set (such as POSIX).
> 
> Shouldn't we do just the opposite?  GNU find doesn't exist on all archs
> (BSD is an example).  There was just an example of GNU extensions being
> used on find that broke on FreeBSD.  It would be more portable to
> *avoid* GNU-only extensions in ebuilds.

I would argue that both are hackish workarounds and the correct solution
is to get upstream to accept patches so that we shouldn't need to use
funky find extensions, BSD or otherwise.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: RFC: sh versionator.eclass

[Steve Long]

Roy Marples wrote:

> On Tue, 2007-10-02 at 17:02 -0600, Joe Peterson wrote:
>> Mike Frysinger wrote:
>> > wrong.  bash and GNU prevail because they provide useful extensions. 
>> > it may be worthwhile to force `find` in the portage environment to be
>> > GNU find so we can stop wasting time trying to figure out how to
>> > rewrite expressions in ebuilds (which can be done trivially with GNU)
>> > with a limited functionality set (such as POSIX).
>> 
>> Shouldn't we do just the opposite?  GNU find doesn't exist on all archs
>> (BSD is an example).  There was just an example of GNU extensions being
>> used on find that broke on FreeBSD.  It would be more portable to
>> *avoid* GNU-only extensions in ebuilds.
> 
> I would argue that both are hackish workarounds and the correct solution
> is to get upstream to accept patches so that we shouldn't need to use
> funky find extensions, BSD or otherwise.
> 
If you have the patches and can make it work consistently on all gentoo
platforms, imo you should just do a custom find for gentoo. Distributing it
to users won't be an issue, and by standardising here you can prove the
benefits, while saving your devs a load of time.

Although, I have to ask: what is so terrible about installing GNU findutils?
Personally I'd just build in a chroot if the pollution were that bad.
(AFAICT the whole point of GNU stuff is to have a consistent Free
foundation. But like you said, that's next month ;P)


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: sh versionator.eclass

[Roy Marples]

On Wed, 2007-10-03 at 01:55 +0100, Steve Long wrote:
> If you have the patches and can make it work consistently on all gentoo
> platforms, imo you should just do a custom find for gentoo. Distributing it
> to users won't be an issue, and by standardising here you can prove the
> benefits, while saving your devs a load of time.

I meant patching the upstream for the stuff the ebuild is installing so
that using find isn't required.

> 
> Although, I have to ask: what is so terrible about installing GNU findutils?
> Personally I'd just build in a chroot if the pollution were that bad.
> (AFAICT the whole point of GNU stuff is to have a consistent Free
> foundation. But like you said, that's next month ;P)

There's the fact it doesn't actually build on BSD.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: sh versionator.eclass

[Fabian Groffen]

On 03-10-2007 09:40:02 +0100, Roy Marples wrote:
> > Although, I have to ask: what is so terrible about installing GNU findutils?
> > Personally I'd just build in a chroot if the pollution were that bad.
> > (AFAICT the whole point of GNU stuff is to have a consistent Free
> > foundation. But like you said, that's next month ;P)
> 
> There's the fact it doesn't actually build on BSD.

[horus:/export/scratch/gentoo] % which find
/export/scratch/gentoo/tmp/usr/bin/find
[horus:/export/scratch/gentoo] % find --version
GNU find version 4.2.27
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION 
[horus:/export/scratch/gentoo] % uname -a
FreeBSD horus 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan
12 10:40:27 UTC 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 i386 Pentium II/Pentium II Xeon/Celeron FreeBSD

 

-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Mike Frysinger]

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

On Tuesday 02 October 2007, Joe Peterson wrote:
> Mike Frysinger wrote:
> > wrong.  bash and GNU prevail because they provide useful extensions.  it
> > may be worthwhile to force `find` in the portage environment to be GNU
> > find so we can stop wasting time trying to figure out how to rewrite
> > expressions in ebuilds (which can be done trivially with GNU) with a
> > limited functionality set (such as POSIX).
>
> Shouldn't we do just the opposite?  GNU find doesn't exist on all archs
> (BSD is an example).  There was just an example of GNU extensions being
> used on find that broke on FreeBSD.  It would be more portable to
> *avoid* GNU-only extensions in ebuilds.

as mentioned, GNU is the main bread and butter of Gentoo.  forcing the 
majority of people to go pure POSIX in the face of GNU extensions that make 
life easier is wrong.  so the minority gets screwed, that's life.  especially 
considering it's trivial for the minority to conform.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] RFC: sh versionator.eclass

[Joe Peterson]

Mike Frysinger wrote:
> as mentioned, GNU is the main bread and butter of Gentoo.  forcing the 
> majority of people to go pure POSIX in the face of GNU extensions that make 
> life easier is wrong.  so the minority gets screwed, that's life.  especially 
> considering it's trivial for the minority to conform.
> -mike

Hi Mike,

I totally agree that we should be careful about trying to force pure
POSIX on ebuild writers, and you are right that GNU is the majority.  I
do see an issue here, though, and I am not sure what the best solution is.

Ebuilds have to work across various platforms, including the Gentoo/Alt
ones, and it is common practice to use external tools (like "find",
etc.), and unlike eclasses, they can behave differently on different
platforms (at least the way things are set up now).  Ebuilds already
have to limit themselves to using tools from a core set that exist on
all systems, of course, but if options to these tools are used that do
not exist on all platforms, the ebuild is not portable, and that's the
crux of the issue.

So there are a couple of options, as I see it:

1) Limit tool options to those that are common to all tool variants
2) Port a standard (i.e. GNU) set of tools to all platforms
3) Force all gentoo ports to use GNU userland

I think we'd all agree that #3 is too restrictive.  For example, g/fbsd
uses BSD's userland (like vanilla FreeBSD does), and making it GNU would
be a pretty major change.  #2 is would be feasible, but namespace
collisions would result unless we did something like prepend "g" to the
tools and perhaps place them in a standard dir where ebuilds will look
for them first.  This would even more formally define the core set of
tools allowed, and I'm not sure if this is a good or bad thing.  #1 is
the one you object to, and I am torn on this one.  I agree with you that
we don't necessarily want to deny ebuilds nice features included in only
the GNU variants, but then again, the Gentoo Development Guide does
recommend avoiding GNU-specific options for, I assume, this reason:
	http://devmanual.gentoo.org/tools-reference/find/index.html

So, comments?

						-Joe
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Fabian Groffen]

On 07-10-2007 10:19:43 -0600, Joe Peterson wrote:
> So there are a couple of options, as I see it:
> 
> 1) Limit tool options to those that are common to all tool variants
> 2) Port a standard (i.e. GNU) set of tools to all platforms
> 3) Force all gentoo ports to use GNU userland
> 
> I think we'd all agree that #3 is too restrictive.  For example, g/fbsd
> uses BSD's userland (like vanilla FreeBSD does), and making it GNU would
> be a pretty major change.

No, it is not.  The problem IMHO is in the "user" userland and the
"portage" userland are being seen as one.  I think it would be very easy
to install all GNU equivalents of tools on BSD in some separate dir, put
it in portage's DEFAULT_PATH before /bin and /usr/bin and all would work
perfectly well from the ebuild/eclass perspective.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Joe Peterson]

Fabian Groffen wrote:
> On 07-10-2007 10:19:43 -0600, Joe Peterson wrote:
>> So there are a couple of options, as I see it:
>>
>> 1) Limit tool options to those that are common to all tool variants
>> 2) Port a standard (i.e. GNU) set of tools to all platforms
>> 3) Force all gentoo ports to use GNU userland
>>
>> I think we'd all agree that #3 is too restrictive.  For example, g/fbsd
>> uses BSD's userland (like vanilla FreeBSD does), and making it GNU would
>> be a pretty major change.
> 
> No, it is not.  The problem IMHO is in the "user" userland and the
> "portage" userland are being seen as one.  I think it would be very easy
> to install all GNU equivalents of tools on BSD in some separate dir, put
> it in portage's DEFAULT_PATH before /bin and /usr/bin and all would work
> perfectly well from the ebuild/eclass perspective.

Yep, that's option #2, and I think that could work - a subset of
commands in their GNU variants used by portage.  It means formalizing
the official set of tools allowed for use in ebuilds (I'm not sure if
the dev guide really codifies this or not, even though it gives a list
of such tools).

What I meant above is that #3, which would be changing all of userland
itself to GNU, would be major and undesirable.  Having the option of a
complete GNU userland would be an interesting option/project, but it's a
good thing to have the flexibility to have any userland desired, as long
as portage has a way of being consistent (i.e. via something like #2).

					-Joe

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Fabian Groffen]

On 07-10-2007 16:37:21 -0600, Joe Peterson wrote:
> >> 1) Limit tool options to those that are common to all tool variants
> >> 2) Port a standard (i.e. GNU) set of tools to all platforms
> >> 3) Force all gentoo ports to use GNU userland
...
> > No, it is not.  The problem IMHO is in the "user" userland and the
> > "portage" userland are being seen as one.  I think it would be very easy
> > to install all GNU equivalents of tools on BSD in some separate dir, put
> > it in portage's DEFAULT_PATH before /bin and /usr/bin and all would work
> > perfectly well from the ebuild/eclass perspective.
> 
> Yep, that's option #2, and I think that could work - a subset of
> commands in their GNU variants used by portage.  It means formalizing
> the official set of tools allowed for use in ebuilds (I'm not sure if
> the dev guide really codifies this or not, even though it gives a list
> of such tools).

Ok, then I misunderstood.  Most important thing is that we agree that
this looks like it /is/ the way to go.




> What I meant above is that #3, which would be changing all of userland
> itself to GNU, would be major and undesirable.  Having the option of a
> complete GNU userland would be an interesting option/project, but it's a
> good thing to have the flexibility to have any userland desired, as long
> as portage has a way of being consistent (i.e. via something like #2).

If you want a GNU userland on FreeBSD, Solaris, Darwin, etc. I think you
should look at Prefix where [[ ${USERLAND} == "GNU" ]] always holds. ;)


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Mike Frysinger]

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

On Sunday 07 October 2007, Fabian Groffen wrote:
> On 07-10-2007 10:19:43 -0600, Joe Peterson wrote:
> > So there are a couple of options, as I see it:
> >
> > 1) Limit tool options to those that are common to all tool variants
> > 2) Port a standard (i.e. GNU) set of tools to all platforms
> > 3) Force all gentoo ports to use GNU userland
> >
> > I think we'd all agree that #3 is too restrictive.  For example, g/fbsd
> > uses BSD's userland (like vanilla FreeBSD does), and making it GNU would
> > be a pretty major change.
>
> No, it is not.  The problem IMHO is in the "user" userland and the
> "portage" userland are being seen as one.  I think it would be very easy
> to install all GNU equivalents of tools on BSD in some separate dir, put
> it in portage's DEFAULT_PATH before /bin and /usr/bin and all would work
> perfectly well from the ebuild/eclass perspective.

Fabian has summed it up nicely, thanks.  i could care less what your userland 
is outside of the ebuild environment since it doesnt matter to ebuild 
writers.  you want a deficient runtime environment, more power to you, but 
forcing that environment onto ebuild developers is not acceptable.  off the 
top of my head, i'd like to see GNU find/xargs added to the ebuild 
environment.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] RFC: sh versionator.eclass

[Joe Peterson]

Mike Frysinger wrote:
> Fabian has summed it up nicely, thanks.  i could care less what your userland 
> is outside of the ebuild environment since it doesnt matter to ebuild 
> writers.  you want a deficient runtime environment, more power to you, but 
> forcing that environment onto ebuild developers is not acceptable.  off the 
> top of my head, i'd like to see GNU find/xargs added to the ebuild 
> environment.
> -mike

Mike, exactly as I said.  That's option #2, and I think it could be a
great solution.  As for deficient, well, that's in the eye of the
beholder.  ;)

						-Joe
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)

[Natanael Copa]

On Sun, 2007-10-07 at 21:26 -0600, Joe Peterson wrote:
> Mike Frysinger wrote:
> > Fabian has summed it up nicely, thanks.  i could care less what your userland 
> > is outside of the ebuild environment since it doesnt matter to ebuild 
> > writers.  you want a deficient runtime environment, more power to you, but 
> > forcing that environment onto ebuild developers is not acceptable.  off the 
> > top of my head, i'd like to see GNU find/xargs added to the ebuild 
> > environment.
> > -mike
> 
> Mike, exactly as I said.  That's option #2, and I think it could be a
> great solution.  As for deficient, well, that's in the eye of the
> beholder.  ;)
> 
> 						-Joe

Question, if you go for #2. Does that mean you will need all the
required GNU userland to do binary only installs?

It would be highly desireable to be able to do binary installs (write
your own binary only package manager) without depending on all the GNU
stuff needed to compile the packages.

-nc

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)

[Alec Warner]

On 10/8/07, Natanael Copa <natanael.copa@gmail.com> wrote:
> On Sun, 2007-10-07 at 21:26 -0600, Joe Peterson wrote:
> > Mike Frysinger wrote:
> > > Fabian has summed it up nicely, thanks.  i could care less what your userland
> > > is outside of the ebuild environment since it doesnt matter to ebuild
> > > writers.  you want a deficient runtime environment, more power to you, but
> > > forcing that environment onto ebuild developers is not acceptable.  off the
> > > top of my head, i'd like to see GNU find/xargs added to the ebuild
> > > environment.
> > > -mike
> >
> > Mike, exactly as I said.  That's option #2, and I think it could be a
> > great solution.  As for deficient, well, that's in the eye of the
> > beholder.  ;)
> >
> >                                               -Joe
>
> Question, if you go for #2. Does that mean you will need all the
> required GNU userland to do binary only installs?
>
> It would be highly desireable to be able to do binary installs (write
> your own binary only package manager) without depending on all the GNU
> stuff needed to compile the packages.

Your own binary only package manager would still need to provide
Option #2; ie you need to have GNU tools installed to process the
binary packages.  pkg_* functions could still have GNU stuff in them
and those still get run during a binary package install.

-Alec
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)

[Natanael Copa]

On Mon, 2007-10-08 at 06:52 -0700, Alec Warner wrote:
> On 10/8/07, Natanael Copa <natanael.copa@gmail.com> wrote:
> > On Sun, 2007-10-07 at 21:26 -0600, Joe Peterson wrote:
> > > Mike Frysinger wrote:
> > > > Fabian has summed it up nicely, thanks.  i could care less what your userland
> > > > is outside of the ebuild environment since it doesnt matter to ebuild
> > > > writers.  you want a deficient runtime environment, more power to you, but
> > > > forcing that environment onto ebuild developers is not acceptable.  off the
> > > > top of my head, i'd like to see GNU find/xargs added to the ebuild
> > > > environment.
> > > > -mike
> > >
> > > Mike, exactly as I said.  That's option #2, and I think it could be a
> > > great solution.  As for deficient, well, that's in the eye of the
> > > beholder.  ;)
> > >
> > >                                               -Joe
> >
> > Question, if you go for #2. Does that mean you will need all the
> > required GNU userland to do binary only installs?
> >
> > It would be highly desireable to be able to do binary installs (write
> > your own binary only package manager) without depending on all the GNU
> > stuff needed to compile the packages.
> 
> Your own binary only package manager would still need to provide
> Option #2; ie you need to have GNU tools installed to process the
> binary packages.  pkg_* functions could still have GNU stuff in them
> and those still get run during a binary package install.

If we would like to be able to do binary installs without the GNU tools,
what alternatives do we have?

Those pops up to my mind:

A. move the pkg_* functions out of the ebuild to a separate file. Those
have a subset of the EAPI and needs to be posix compliant.

B. don't use GNU extensions in pkg_functions and have some way to export
them (extract pkg_* functions from environment.bz2). Those can then be
used by pre/post script in binary package manager.

C. Binary package managers will need to write their own pre/post
scripts.


Any other alternatives?

Comments?


Alternative C is what I do today.

-nc

> 
> -Alec

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: GNU userland and binary package (WAS: RFC: sh versionator.eclass)

[Steve Long]

Natanael Copa wrote:

> On Mon, 2007-10-08 at 06:52 -0700, Alec Warner wrote:
>> On 10/8/07, Natanael Copa <natanael.copa@gmail.com> wrote:
>> > On Sun, 2007-10-07 at 21:26 -0600, Joe Peterson wrote:
>> > > Mike Frysinger wrote:
>> > > > Fabian has summed it up nicely, thanks.  i could care less what
>> > > > your userland is outside of the ebuild environment since it doesnt
>> > > > matter to ebuild
>> > > > writers.  you want a deficient runtime environment, more power to
>> > > > you, but
>> > > > forcing that environment onto ebuild developers is not acceptable. 
>> > > > off the top of my head, i'd like to see GNU find/xargs added to the
>> > > > ebuild environment.
>> > >
>> > > Mike, exactly as I said.  That's option #2, and I think it could be a
>> > > great solution.  As for deficient, well, that's in the eye of the
>> > > beholder.  ;)
>> > >
++ on the general idea: GNU sed, grep, awk, ed and find get my vote (as well
as BASH ofc.) (I don't /think/ you need xargs anymore with find .. -exec.)

>> >
>> > Question, if you go for #2. Does that mean you will need all the
>> > required GNU userland to do binary only installs?
>> >
>> > It would be highly desireable to be able to do binary installs (write
>> > your own binary only package manager) without depending on all the GNU
>> > stuff needed to compile the packages.
>>
Well all you're talking about is BASH and a few others on the machine that
builds the binaries afaict. I don't see that as a major imposition. You can
then package for downstream using whatever you like.

If you're that motivated why not just start hacking on binary support in
portage/pkgcore/paludis? There's always open bugs.

>> Your own binary only package manager would still need to provide
>> Option #2; ie you need to have GNU tools installed to process the
>> binary packages.  pkg_* functions could still have GNU stuff in them
>> and those still get run during a binary package install.
> 
> If we would like to be able to do binary installs without the GNU tools,
> what alternatives do we have?
> 
<snip stuff that all takes a lot of effort for zero end-user gain>

> Any other alternatives?
> 
> Comments?
>
I'd just specify BASH (as I don't see the point in making the distinction as
it only applies to build machines) and coreutils/findutils etc.
Asking everyone to switch coding style for certain functions, just to
support the stuff that Gentoo was designed to do from the beginning, seems
counter-productive. For every market except embedded, which we've discussed
already, BASH is not a major issue: nor are the other tools mentioned.
> 
> Alternative C is what I do today.
> 
Sounds rough :)
(I really would recommend #pkgcore as well as there is several years of work
to do with binpkgs in that.)

Standardising on a certain subset of base GNU tools seems like a good idea
to me too.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GNU userland and binary package (WAS: RFC: sh versionator.eclass)

[Natanael Copa]

On Mon, 2007-10-08 at 20:25 +0100, Steve Long wrote:
> Natanael Copa wrote:

> If you're that motivated why not just start hacking on binary support in
> portage/pkgcore/paludis? There's always open bugs.

I think I did contribute with some patches for qmerge in portage-utils.

Unfortunally, its pretty difficult to make a lightweight C (language)
only binary installer without having at least the eclasses and GNU
tools.

It kind of defeat the idea of having a lightweight binary only runtime
environment. (lightweight means busybox - which give you most of the
basic GNU tools, linux-utils, wget, shell, http server and much more for
the size of bash only)

> >> Your own binary only package manager would still need to provide
> >> Option #2; ie you need to have GNU tools installed to process the
> >> binary packages.  pkg_* functions could still have GNU stuff in them
> >> and those still get run during a binary package install.
> > 
> > If we would like to be able to do binary installs without the GNU tools,
> > what alternatives do we have?
> > 
> <snip stuff that all takes a lot of effort for zero end-user gain>
> 
> > Any other alternatives?
> > 
> > Comments?
> >
> I'd just specify BASH (as I don't see the point in making the distinction as
> it only applies to build machines) and coreutils/findutils etc.

To properly install a prebuilt binary packages you need the pkg_* funcs
in the ebuild.

> Asking everyone to switch coding style for certain functions, just to
> support the stuff that Gentoo was designed to do from the beginning, seems
> counter-productive. 

We already do different for init.d scripts (which is great!) , but sure,
I get the point.

> For every market except embedded, which we've discussed
> already, BASH is not a major issue: nor are the other tools mentioned.

I happen to do embedded.

> > 
> > Alternative C is what I do today.
> > 
> Sounds rough :)

Thats why I'm interested in alternatives.

> (I really would recommend #pkgcore as well as there is several years of work
> to do with binpkgs in that.)

So far no packagemanager using the portage stuff (eclasses) are not even
close to compete in size for binary only installs. Closest is
portage-utils's qmerge but it would need atleast the eclasses and bash
which would atleast double the size in comparison what I do today.

Looks like i will need to continue do my own stuff.

Thanks for you time!

> Standardising on a certain subset of base GNU tools seems like a good idea
> to me too.

-nc

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: GNU userland and binary package (WAS: RFC: sh versionator.eclass)

[Steve Long]

Natanael Copa wrote:

> On Mon, 2007-10-08 at 20:25 +0100, Steve Long wrote:
>> Natanael Copa wrote:
> 
>> If you're that motivated why not just start hacking on binary support in
>> portage/pkgcore/paludis? There's always open bugs.
> 
> I think I did contribute with some patches for qmerge in portage-utils.
>
Nice one! I really like portage-utils, they're good and fast.

> Unfortunally, its pretty difficult to make a lightweight C (language)
> only binary installer without having at least the eclasses and GNU
> tools.
> 
> It kind of defeat the idea of having a lightweight binary only runtime
> environment. (lightweight means busybox - which give you most of the
> basic GNU tools, linux-utils, wget, shell, http server and much more for
> the size of bash only)
>
Yes but build time is not the same as runtime, especially for embedded
systems. Installation doesn't have to be run by the target, which typically
uses an image.

>> I'd just specify BASH (as I don't see the point in making the distinction
>> as it only applies to build machines) and coreutils/findutils etc.
> 
> To properly install a prebuilt binary packages you need the pkg_* funcs
> in the ebuild.
> 
>> Asking everyone to switch coding style for certain functions, just to
>> support the stuff that Gentoo was designed to do from the beginning,
>> seems counter-productive.
> 
> We already do different for init.d scripts (which is great!) , but sure,
> I get the point.
>
That's entirely proper and reasonable to me, since it means the installed
system can use whatever shell it likes.

>> For every market except embedded, which we've discussed
>> already, BASH is not a major issue: nor are the other tools mentioned.
> 
> I happen to do embedded.
>
I don't understand then why you cannot build images using whatever tools you
like and then simply run them using the targets. Apologies if I am missing
something.

>> > 
>> > Alternative C is what I do today.
>> > 
>> Sounds rough :)
> 
> Thats why I'm interested in alternatives.
> 
>> (I really would recommend #pkgcore as well as there is several years of
>> work to do with binpkgs in that.)
> 
> So far no packagemanager using the portage stuff (eclasses) are not even
> close to compete in size for binary only installs. Closest is
> portage-utils's qmerge but it would need atleast the eclasses and bash
> which would atleast double the size in comparison what I do today.
> 
> Looks like i will need to continue do my own stuff.
> 
> Thanks for you time!
>
Good luck with it! I recommend #gentoo-embedded on irc.freenode.org btw;
##electronics is good. Some of the bods in #gentoo-chat have experience
with this kinda thing as well, and you'd be welcome in #friendly-coders.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)

[Alec Warner]

On 10/8/07, Natanael Copa <natanael.copa@gmail.com> wrote:
> On Mon, 2007-10-08 at 06:52 -0700, Alec Warner wrote:
> > On 10/8/07, Natanael Copa <natanael.copa@gmail.com> wrote:
> > > On Sun, 2007-10-07 at 21:26 -0600, Joe Peterson wrote:
> > > > Mike Frysinger wrote:
> > > > > Fabian has summed it up nicely, thanks.  i could care less what your userland
> > > > > is outside of the ebuild environment since it doesnt matter to ebuild
> > > > > writers.  you want a deficient runtime environment, more power to you, but
> > > > > forcing that environment onto ebuild developers is not acceptable.  off the
> > > > > top of my head, i'd like to see GNU find/xargs added to the ebuild
> > > > > environment.
> > > > > -mike
> > > >
> > > > Mike, exactly as I said.  That's option #2, and I think it could be a
> > > > great solution.  As for deficient, well, that's in the eye of the
> > > > beholder.  ;)
> > > >
> > > >                                               -Joe
> > >
> > > Question, if you go for #2. Does that mean you will need all the
> > > required GNU userland to do binary only installs?
> > >
> > > It would be highly desireable to be able to do binary installs (write
> > > your own binary only package manager) without depending on all the GNU
> > > stuff needed to compile the packages.
> >
> > Your own binary only package manager would still need to provide
> > Option #2; ie you need to have GNU tools installed to process the
> > binary packages.  pkg_* functions could still have GNU stuff in them
> > and those still get run during a binary package install.
>
> If we would like to be able to do binary installs without the GNU tools,
> what alternatives do we have?
>
> Those pops up to my mind:
>
> A. move the pkg_* functions out of the ebuild to a separate file. Those
> have a subset of the EAPI and needs to be posix compliant.

This is just rife with complications, IMHO.  Two files per ebuild
revision?  Shared pre/post functions?  Extra manifests, stats,
sourcing, bigger tree, inode requirements.  Probably not an easy sell
here.

>
> B. don't use GNU extensions in pkg_functions and have some way to export
> them (extract pkg_* functions from environment.bz2). Those can then be
> used by pre/post script in binary package manager.

This is your best bet, but again mandates are ineffective.  As you've
no doubt noticed with quoting, people will do whatever works and the
people who aim for odd targets like no GNU crap or sh compatability
are going to have to do the code reviews and encourage that sort of
thing.  Just saying 'pre/post functions must be POSIX compatable' will
get you nowhere.  The point here is to sell your idea to other
developers; if you can't sell it you may need to take it elsewhere.

>
> C. Binary package managers will need to write their own pre/post
> scripts

Good luck with this route; you may be able to write replacements for
most utilities but I bet the conversion would still fail on weird
constructs.

D.  Keep your own ebuilds.  Particularly for embedded you probably
aren't using a ton of them anyway and given a sufficient pool of
developers interested in POSIX compatible ebuilds you could probably
hammer out a posix-compliant embedded tree in short order.  I know
everyone hates option D; but I'm also kind of irritated by everyone
trying to push weird requirements on everyone else.  If you can't
convince the majority of developers to do thing X, you may end up
having to do it yourself; welcome to open source software ;)

-Alec
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)

[Roy Marples]

On Wed, 2007-10-10 at 20:03 -0700, Alec Warner wrote:
> > B. don't use GNU extensions in pkg_functions and have some way to export
> > them (extract pkg_* functions from environment.bz2). Those can then be
> > used by pre/post script in binary package manager.
> 
> This is your best bet, but again mandates are ineffective.  As you've
> no doubt noticed with quoting, people will do whatever works and the
> people who aim for odd targets like no GNU crap or sh compatability
> are going to have to do the code reviews and encourage that sort of
> thing.  Just saying 'pre/post functions must be POSIX compatable' will
> get you nowhere.  The point here is to sell your idea to other
> developers; if you can't sell it you may need to take it elsewhere.

This is what I'm preaching, but for the whole ebuild not just the
pre/post functions.

It's a tough crowd as everyone's a zealot with their own favourite "must
have" tools + the territorial crap which rears it's ugly head from time
to time.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Mike Frysinger]

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

On Tuesday 02 October 2007, Roy Marples wrote:
> On Tue, 2007-10-02 at 09:29 +0200, Fabian Groffen wrote:
> > On 01-10-2007 22:59:40 +0100, Roy Marples wrote:
> > > I would like to propse a new versionator.eclass for consideration
> > > (attached).
> > >
> > > This version, I believe, is more readable and maintainable then the one
> > > currently in portage. It also uses a lot less code and has the bonus of
> > > being pure sh.
> >
> > What is your rationale to say that "pure sh" is a "bonus"?  Especially
> > given the environment this is used in as ferdy already pointed out?
>
> The bonus is that it works on shells other than bash.

which is irrelevant here

> > I personally like consistency.  So if we use bash in ebuilds, then I'd
> > like to use bash in eclasses too.  I'm interested in your motivation to
> > make this eclass "pure sh", whatever that may mean.
>
> I like consistency too, and I'll be pushing for using sh instead of
> forcing bash.

pushing a new standard by slowly converting the tree is not the way to go.

> My motivation? Simple. I don't believe that the portage tree should be
> locked into using one shell. I believe that vendor lock-in should happen
> at the social level, not the technical one. portage itself was a lock-in
> until until PMS came about, now I'd like to remove the lock-in from the
> tree itself. This in itself is a good thing as we can pick and choose
> the tools we want to use as they're all playing on the same field.

POSIX lacks useful bash extensions that are used heavily ... arrays, string 
replacements, pattern matching with [[ == ]] to name some.  here's 
your "technical" reason for using the bash standard over POSIX: it's 
superior.

> This same rationale applies to scriptlets outside portage tree use, such
> as revdep-rebuild [1]. It's more of a bashlet, but I've also
> demonstrated that there was no reason to force bash there.

not really ... there's a reason the environment dictated inside of the package 
manager requires GNU stuff ... the extensions provided make life easy.  all 
this conversion from trivial GNU extensions to limited POSIX interfaces is a 
pita (as can trivially be seen with find and xargs).  as for "no reason", 
just because it can be done differently doesnt mean it should.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] RFC: sh versionator.eclass

[Roy Marples]

On Tue, 2007-10-02 at 05:39 -0400, Mike Frysinger wrote:
> > The bonus is that it works on shells other than bash.
> 
> which is irrelevant here

I think otherwise.
> 
> > > I personally like consistency.  So if we use bash in ebuilds, then I'd
> > > like to use bash in eclasses too.  I'm interested in your motivation to
> > > make this eclass "pure sh", whatever that may mean.
> >
> > I like consistency too, and I'll be pushing for using sh instead of
> > forcing bash.
> 
> pushing a new standard by slowly converting the tree is not the way to go.

That's why I'm here talking, trying to convince people. Some people like
yourself will never be convinced though.


> POSIX lacks useful bash extensions that are used heavily ... arrays, string 
> replacements, pattern matching with [[ == ]] to name some.  here's 
> your "technical" reason for using the bash standard over POSIX: it's 
> superior.

POSIX has positional parameters, which provide array like functionality.
I would argue that this is better as you cannot pass an array to a
function - you have to pass it as positional parameters.
I agree that the bash array is superior as you can grab the index of
items >=10 easily and walk it backwards, but I've yet to see a case
where it cannot be done otherwise.

Pattern matching can be done just as well with case. Infact, tend to use
[[ == ]] a lot when pattern matching when a case statement would be more
efficient and use less code. Of course when you're just interested in
matching one one thing in a code block then it uses more code, but that
is probably outside the norm.

String replacements. This is the real bug bear isn't it? sh has no easy
answer to this, but that doesn't mean that we can't use it. We use many
eclass specific functions, so why not have another?
foo=${haystack//needle/thread}
foo="$(ereplace "${haystack}" "${needle}" "${thread}")"

I already have sh code that handles that as we can't call external bins
in global scope for ebuilds. But for everything else there's sed.

> > This same rationale applies to scriptlets outside portage tree use, such
> > as revdep-rebuild [1]. It's more of a bashlet, but I've also
> > demonstrated that there was no reason to force bash there.
> 
> not really ... there's a reason the environment dictated inside of the package 
> manager requires GNU stuff ... the extensions provided make life easy.  all 
> this conversion from trivial GNU extensions to limited POSIX interfaces is a 
> pita (as can trivially be seen with find and xargs).  as for "no reason", 
> just because it can be done differently doesnt mean it should.

Using the same argument, just because there is a GNU extension does not
mean it should be used.

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Mike Frysinger]

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

On Tuesday 02 October 2007, Roy Marples wrote:
> On Tue, 2007-10-02 at 05:39 -0400, Mike Frysinger wrote:
> > > > I personally like consistency.  So if we use bash in ebuilds, then
> > > > I'd like to use bash in eclasses too.  I'm interested in your
> > > > motivation to make this eclass "pure sh", whatever that may mean.
> > >
> > > I like consistency too, and I'll be pushing for using sh instead of
> > > forcing bash.
> >
> > pushing a new standard by slowly converting the tree is not the way to
> > go.
>
> That's why I'm here talking, trying to convince people. Some people like
> yourself will never be convinced though.

i am convinced by superior standards and by good things.  forcing the standard 
from bash to POSIX is neither of these.  i dont see that as a flaw in my 
logic.

> > POSIX lacks useful bash extensions that are used heavily ... arrays,
> > string replacements, pattern matching with [[ == ]] to name some.  here's
> > your "technical" reason for using the bash standard over POSIX: it's
> > superior.
>
> POSIX has positional parameters, which provide array like functionality.
> I would argue that this is better as you cannot pass an array to a
> function - you have to pass it as positional parameters.

having the option leads to better code.  sometimes positional parameter usage 
is a better idea, sometimes it is not.

> I agree that the bash array is superior as you can grab the index of
> items >=10 easily and walk it backwards, but I've yet to see a case
> where it cannot be done otherwise.

positional parameters provide a workaround for *1* array.  what if you need 
two ?  three ?  well damn, you're pickled in the pooper i think.

> Pattern matching can be done just as well with case. Infact, tend to use
> [[ == ]] a lot when pattern matching when a case statement would be more
> efficient and use less code. Of course when you're just interested in
> matching one one thing in a code block then it uses more code, but that
> is probably outside the norm.

case statements can be used in place of *some* statements, but not nearly all 
and certainly does not provide the extended logic combining capabilities.  
need to do boolean logic ?  say hello to convoluted nested case statements!

> String replacements. This is the real bug bear isn't it? sh has no easy
> answer to this, but that doesn't mean that we can't use it. We use many
> eclass specific functions, so why not have another?
> foo=${haystack//needle/thread}
> foo="$(ereplace "${haystack}" "${needle}" "${thread}")"
>
> I already have sh code that handles that as we can't call external bins
> in global scope for ebuilds. But for everything else there's sed.

i dont buy either of these as "solutions" but "workarounds".  "workarounds" 
get punted for "solutions".

> > > This same rationale applies to scriptlets outside portage tree use,
> > > such as revdep-rebuild [1]. It's more of a bashlet, but I've also
> > > demonstrated that there was no reason to force bash there.
> >
> > not really ... there's a reason the environment dictated inside of the
> > package manager requires GNU stuff ... the extensions provided make life
> > easy.  all this conversion from trivial GNU extensions to limited POSIX
> > interfaces is a pita (as can trivially be seen with find and xargs).  as
> > for "no reason", just because it can be done differently doesnt mean it
> > should.
>
> Using the same argument, just because there is a GNU extension does not
> mean it should be used.

yes it does.  here's the scenario: use 1 find statement that is clear and 
concise (but requires a GNU extension) or chain 1 find statement into 
multiple other programs and combine it with shell code.  you get the same 
result, but the former is a ton easier to maintain.  bogus scenario you say ?  
i just dealt with it.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] RFC: sh versionator.eclass

[Roy Marples]

On Tue, 2007-10-02 at 06:57 -0400, Mike Frysinger wrote:
> i am convinced by superior standards and by good things.  forcing the standard 
> from bash to POSIX is neither of these.  i dont see that as a flaw in my 
> logic.

Forcing? I'm not asking for anything to be forced, I'm asking for it to
be allowed.

By the same token, I don't force anyone to write a sh init script and I
allow bash init scripts in baselayout.

> positional parameters provide a workaround for *1* array.  what if you need 
> two ?  three ?  well damn, you're pickled in the pooper i think.

Not exactly true, you can use multi dimensional arrays through eval
usage. Nasty I know, but I think the same thing about arrays like so
anyway.

> > Pattern matching can be done just as well with case. Infact, tend to use
> > [[ == ]] a lot when pattern matching when a case statement would be more
> > efficient and use less code. Of course when you're just interested in
> > matching one one thing in a code block then it uses more code, but that
> > is probably outside the norm.
> 
> case statements can be used in place of *some* statements, but not nearly all 
> and certainly does not provide the extended logic combining capabilities.  
> need to do boolean logic ?  say hello to convoluted nested case statements!

Then variables should be used to make the code readable.

> > String replacements. This is the real bug bear isn't it? sh has no easy
> > answer to this, but that doesn't mean that we can't use it. We use many
> > eclass specific functions, so why not have another?
> > foo=${haystack//needle/thread}
> > foo="$(ereplace "${haystack}" "${needle}" "${thread}")"
> >
> > I already have sh code that handles that as we can't call external bins
> > in global scope for ebuilds. But for everything else there's sed.
> 
> i dont buy either of these as "solutions" but "workarounds".  "workarounds" 
> get punted for "solutions".

By the same token, epatch is a "workaround" to apply non exact patches.
The correct "solution" is to craft an exact patch. So we should punt
epatch too?

> > > > This same rationale applies to scriptlets outside portage tree use,
> > > > such as revdep-rebuild [1]. It's more of a bashlet, but I've also
> > > > demonstrated that there was no reason to force bash there.
> > >
> > > not really ... there's a reason the environment dictated inside of the
> > > package manager requires GNU stuff ... the extensions provided make life
> > > easy.  all this conversion from trivial GNU extensions to limited POSIX
> > > interfaces is a pita (as can trivially be seen with find and xargs).  as
> > > for "no reason", just because it can be done differently doesnt mean it
> > > should.
> >
> > Using the same argument, just because there is a GNU extension does not
> > mean it should be used.
> 
> yes it does.  here's the scenario: use 1 find statement that is clear and 
> concise (but requires a GNU extension) or chain 1 find statement into 
> multiple other programs and combine it with shell code.  you get the same 
> result, but the former is a ton easier to maintain.  bogus scenario you say ?  
> i just dealt with it.

Let me guess - openssl?

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Mike Frysinger]

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

On Tuesday 02 October 2007, Roy Marples wrote:
> On Tue, 2007-10-02 at 06:57 -0400, Mike Frysinger wrote:
> > i am convinced by superior standards and by good things.  forcing the
> > standard from bash to POSIX is neither of these.  i dont see that as a
> > flaw in my logic.
>
> Forcing? I'm not asking for anything to be forced, I'm asking for it to
> be allowed.

it already is allowed.  bash is a superset of POSIX so anything that can be 
done in POSIX can be done in bash.  if you arent after changing the shell 
standard inside of ebuilds to POSIX, then this discussion is moot.  keep it 
all bash so things remain consistent and we're done.

> > positional parameters provide a workaround for *1* array.  what if you
> > need two ?  three ?  well damn, you're pickled in the pooper i think.
>
> Not exactly true, you can use multi dimensional arrays through eval
> usage. Nasty I know, but I think the same thing about arrays like so
> anyway.

i'm fully aware of all the nested hacks that can be done with eval.  that is 
not an acceptable answer.

> > > Pattern matching can be done just as well with case. Infact, tend to
> > > use [[ == ]] a lot when pattern matching when a case statement would be
> > > more efficient and use less code. Of course when you're just interested
> > > in matching one one thing in a code block then it uses more code, but
> > > that is probably outside the norm.
> >
> > case statements can be used in place of *some* statements, but not nearly
> > all and certainly does not provide the extended logic combining
> > capabilities. need to do boolean logic ?  say hello to convoluted nested
> > case statements!
>
> Then variables should be used to make the code readable.

so you'd advocate dropping one perfectly readable/understandable line of code 
for multiple lines of variables/case statements ?  that doesnt make sense.

> > > String replacements. This is the real bug bear isn't it? sh has no easy
> > > answer to this, but that doesn't mean that we can't use it. We use many
> > > eclass specific functions, so why not have another?
> > > foo=${haystack//needle/thread}
> > > foo="$(ereplace "${haystack}" "${needle}" "${thread}")"
> > >
> > > I already have sh code that handles that as we can't call external bins
> > > in global scope for ebuilds. But for everything else there's sed.
> >
> > i dont buy either of these as "solutions" but "workarounds". 
> > "workarounds" get punted for "solutions".
>
> By the same token, epatch is a "workaround" to apply non exact patches.
> The correct "solution" is to craft an exact patch. So we should punt
> epatch too?

these things are not equivalent by any means.  epatch provides a consistent 
interface (both for ebuild writers and users) to apply patches where there 
was none ... this gave us reliable behavior across the board in terms of how 
patches were fed in, applied to the source, and errors were handled as well 
as the output from the process (status messages and helpful debug information 
from failures) ... the fact that epatch attempts with different -p# levels is 
an extension to automate a step that is 99% of the time irrelevant to the 
final result.  these topics do not pertain to string replacements.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

[gentoo-dev] Re: RFC: sh versionator.eclass

[Duncan]

Roy Marples <uberlord@gentoo.org> posted
1191324510.6284.107.camel@uberlaptop.marples.name, excerpted below, on 
Tue, 02 Oct 2007 12:28:30 +0100:

> On Tue, 2007-10-02 at 06:57 -0400, Mike Frysinger wrote:
>> i am convinced by superior standards and by good things.  forcing the
>> standard from bash to POSIX is neither of these.  i dont see that as a
>> flaw in my logic.
> 
> Forcing? I'm not asking for anything to be forced, I'm asking for it to
> be allowed.

Why is this still here on dev?  The thread has long ago become more 
political than technical, it should be on project now.

I'm also rather disappointed no one else has asked that it be taken there 
yet, considering all the protest there was on non-tech discussion here.  
Where did all those folks go?

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

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: sh versionator.eclass

[Alec Warner]

On 10/2/07, Duncan <1i5t5.duncan@cox.net> wrote:
> Roy Marples <uberlord@gentoo.org> posted
> 1191324510.6284.107.camel@uberlaptop.marples.name, excerpted below, on
> Tue, 02 Oct 2007 12:28:30 +0100:
>
> > On Tue, 2007-10-02 at 06:57 -0400, Mike Frysinger wrote:
> >> i am convinced by superior standards and by good things.  forcing the
> >> standard from bash to POSIX is neither of these.  i dont see that as a
> >> flaw in my logic.
> >
> > Forcing? I'm not asking for anything to be forced, I'm asking for it to
> > be allowed.
>
> Why is this still here on dev?  The thread has long ago become more
> political than technical, it should be on project now.
>
> I'm also rather disappointed no one else has asked that it be taken there
> yet, considering all the protest there was on non-tech discussion here.
> Where did all those folks go?

Obviously because this thread is about reviewing a sh based
versionator.eclass which belongs on -dev ;)

>
> --
> 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
>
> --
> gentoo-dev@gentoo.org mailing list
>
>
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: sh versionator.eclass

[Mike Frysinger]

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

On Tuesday 02 October 2007, Duncan wrote:
> Roy Marples <uberlord@gentoo.org> posted
> 1191324510.6284.107.camel@uberlaptop.marples.name, excerpted below, on
>
> Tue, 02 Oct 2007 12:28:30 +0100:
> > On Tue, 2007-10-02 at 06:57 -0400, Mike Frysinger wrote:
> >> i am convinced by superior standards and by good things.  forcing the
> >> standard from bash to POSIX is neither of these.  i dont see that as a
> >> flaw in my logic.
> >
> > Forcing? I'm not asking for anything to be forced, I'm asking for it to
> > be allowed.
>
> Why is this still here on dev?  The thread has long ago become more
> political than technical, it should be on project now.

it is technical in nature.  we're debating the merits of the POSIX spec vs 
bash extensions.  considering any decisions made here affect all developers 
working on ebuilds, moving it to -project would be a disservice.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] RFC: sh versionator.eclass

[Roy Marples]

On Tue, 2007-10-02 at 06:57 -0400, Mike Frysinger wrote:
> > Pattern matching can be done just as well with case. Infact, tend to use
> > [[ == ]] a lot when pattern matching when a case statement would be more
> > efficient and use less code. Of course when you're just interested in
> > matching one one thing in a code block then it uses more code, but that
> > is probably outside the norm.
> 
> case statements can be used in place of *some* statements, but not nearly all 
> and certainly does not provide the extended logic combining capabilities.  
> need to do boolean logic ?  say hello to convoluted nested case statements!

You can also do some pattern matching like so

foo="foo foobar"

[ "${foo%foobar}" = "${foo}" ] || echo "ends with foobar"
[ "${foo#foobar}" = "${foo}" ] || echo "starts with foo"
[ "${foo#* }" = "${foo}" ] || echo "has a space"

So there's no need for convoluted nested case statements.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Mike Frysinger]

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

On Wednesday 03 October 2007, Roy Marples wrote:
> On Tue, 2007-10-02 at 06:57 -0400, Mike Frysinger wrote:
> > > Pattern matching can be done just as well with case. Infact, tend to
> > > use [[ == ]] a lot when pattern matching when a case statement would be
> > > more efficient and use less code. Of course when you're just interested
> > > in matching one one thing in a code block then it uses more code, but
> > > that is probably outside the norm.
> >
> > case statements can be used in place of *some* statements, but not nearly
> > all and certainly does not provide the extended logic combining
> > capabilities. need to do boolean logic ?  say hello to convoluted nested
> > case statements!
>
> You can also do some pattern matching like so
>
> foo="foo foobar"
>
> [ "${foo%foobar}" = "${foo}" ] || echo "ends with foobar"
> [ "${foo#foobar}" = "${foo}" ] || echo "starts with foo"
> [ "${foo#* }" = "${foo}" ] || echo "has a space"
>
> So there's no need for convoluted nested case statements.

"no need" implies that everything can be done, but you started off 
with "some" ... you're still going from one clean logic statement to multiple 
ones where the nested logic gets to be a pita to track.  again, this is a 
sad/unacceptable solution.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] RFC: sh versionator.eclass

[Roy Marples]

On Sun, 2007-10-07 at 01:06 -0400, Mike Frysinger wrote:
> > You can also do some pattern matching like so
> >
> > foo="foo foobar"
> >
> > [ "${foo%foobar}" = "${foo}" ] || echo "ends with foobar"
> > [ "${foo#foobar}" = "${foo}" ] || echo "starts with foo"
> > [ "${foo#* }" = "${foo}" ] || echo "has a space"
> >
> > So there's no need for convoluted nested case statements.
> 
> "no need" implies that everything can be done, but you started off 
> with "some" ...

Yes, the some being =~, which is the only operator I know of that cannot
be done with posix sh

>  you're still going from one clean logic statement to multiple 
> ones where the nested logic gets to be a pita to track.  again, this
> is a sad/unacceptable solution.

OK, it's time to pony up - show me a code snippet which you think a
nested code snipet which you think is unworkable in posix sh when
transitioning from [[ ]] to [ ].

=~ isn't allowed as that's a strict bashism.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Mike Frysinger]

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

On Sunday 07 October 2007, Roy Marples wrote:
> On Sun, 2007-10-07 at 01:06 -0400, Mike Frysinger wrote:
> > > You can also do some pattern matching like so
> > >
> > > foo="foo foobar"
> > >
> > > [ "${foo%foobar}" = "${foo}" ] || echo "ends with foobar"
> > > [ "${foo#foobar}" = "${foo}" ] || echo "starts with foo"
> > > [ "${foo#* }" = "${foo}" ] || echo "has a space"
> > >
> > > So there's no need for convoluted nested case statements.
> >
> > "no need" implies that everything can be done, but you started off
> > with "some" ...
>
> Yes, the some being =~, which is the only operator I know of that cannot
> be done with posix sh
>
> >  you're still going from one clean logic statement to multiple
> > ones where the nested logic gets to be a pita to track.  again, this
> > is a sad/unacceptable solution.
>
> OK, it's time to pony up - show me a code snippet which you think a
> nested code snipet which you think is unworkable in posix sh when
> transitioning from [[ ]] to [ ].

i never mentioned =~.  i already gave perfectly acceptable examples of using 
== with pattern matching and your unacceptable workaround was to use 
[possibly nested] case statements.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

[gentoo-dev] Re: RFC: sh versionator.eclass

[Steve Long]

Mike Frysinger wrote:

> On Tuesday 02 October 2007, Roy Marples wrote:
>> I like consistency too, and I'll be pushing for using sh instead of
>> forcing bash.
> 
> pushing a new standard by slowly converting the tree is not the way to go.
> 
>> My motivation? Simple. I don't believe that the portage tree should be
>> locked into using one shell. I believe that vendor lock-in should happen
>> at the social level, not the technical one.

I don't see why vendor lock-in should happen at the social level? The
technical one is a much better reason to use one tool over another, so long
as we're not getting sucked in to a proprietary dead-end.

>> portage itself was a lock-in 
>> until until PMS came about, now I'd like to remove the lock-in from the
>> tree itself. This in itself is a good thing as we can pick and choose
>> the tools we want to use as they're all playing on the same field.
> 
> POSIX lacks useful bash extensions that are used heavily ... arrays,
> string replacements, pattern matching with [[ == ]] to name some.  here's
> your "technical" reason for using the bash standard over POSIX: it's
> superior.
>
++ There's just too much nice stuff in BASH to drop down to sh to my mind. I
for one would go right off Gentoo if i were forced to write ebuilds in sh.
I accept the argument for initscripts, since an embedded system is not
likely to have bash. But for compile-time (which shouldn't happen on an
embedded target) there simply isn't any real benefit to end-users that I
can see.

>> This same rationale applies to scriptlets outside portage tree use, such
>> as revdep-rebuild [1]. It's more of a bashlet, but I've also
>> demonstrated that there was no reason to force bash there.
> 
> not really ... there's a reason the environment dictated inside of the
> package manager requires GNU stuff ... the extensions provided make life
> easy.  
> all this conversion from trivial GNU extensions to limited POSIX
> interfaces is a pita (as can trivially be seen with find and xargs).  as 
> for "no reason", just because it can be done differently doesnt mean it 
> should.
>
Hear hear: if you're that worried about BASH being too big and slow, why not
spend the _huge_ amount of time it's going to take you to convert the tree
(which is not likely to be welcomed by all ebuild devs) on making BASH
leaner and quicker for the myriad platforms on which it runs?

/me votes for GASH -- Gentoo Assured SHell ;P


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: sh versionator.eclass

[Roy Marples]

On Tue, 2007-10-02 at 13:36 +0100, Steve Long wrote:
> ++ There's just too much nice stuff in BASH to drop down to sh to my mind. I
> for one would go right off Gentoo if i were forced to write ebuilds in sh.

I had this chat with Donnie last night and he pulled the molden ebuild
of the top of his head.

Attached is a patch to make it posix sh. Infact, most ebuilds themselves
would be that trivial.

So what's the "nice stuff" that's in use? Got any ebuild examples?

> I accept the argument for initscripts, since an embedded system is not
> likely to have bash. But for compile-time (which shouldn't happen on an
> embedded target) there simply isn't any real benefit to end-users that I
> can see.

The benefit is that our portage tree uses an accepted standardised
syntax. bash is just a standard to itself.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: sh versionator.eclass

[Roy Marples]

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

On Tue, 2007-10-02 at 15:18 +0100, Roy Marples wrote:
> Attached is a patch to make it posix sh.

And here it is

[-- Attachment #2: molden-sh.patch --]
[-- Type: text/x-patch, Size: 1318 bytes --]

Index: molden-4.6.ebuild
===================================================================
RCS file: /var/cvsroot/gentoo-x86/sci-chemistry/molden/molden-4.6.ebuild,v
retrieving revision 1.3
diff -u -B -r1.3 molden-4.6.ebuild
--- molden-4.6.ebuild	30 Jul 2007 12:22:49 -0000	1.3
+++ molden-4.6.ebuild	2 Oct 2007 14:14:13 -0000
@@ -28,7 +28,7 @@
 	unpack ${A}
 	cd "${S}"
 
-	if [[ "${FORTRANC}" = "gfortran" ]]; then
+	if [ "${FORTRANC}" = "gfortran" ]; then
 		epatch "${FILESDIR}"/${P}-gfortran.patch
 	fi
 }
@@ -37,18 +37,14 @@
 	# Use -mieee on alpha, according to the Makefile
 	use alpha && append-flags -mieee
 
-	# Honor CC, CFLAGS, FC, and FFLAGS from environment;
-	# unfortunately a bash bug prevents us from doing typeset and
-	# assignment on the same line.
-	typeset -a args
-	args=( CC="$(tc-getCC) ${CFLAGS}" \
-		FC="${FORTRANC}" LDR="${FORTRANC}" FFLAGS="${FFLAGS}" )
+	set -- CC="$(tc-getCC) ${CFLAGS}" \
+		FC="${FORTRANC}" LDR="${FORTRANC}" FFLAGS="${FFLAGS}"
 
 	einfo "Building Molden..."
-	emake -j1 "${args[@]}" || die "molden emake failed"
+	emake -j1 "$@" || die "molden emake failed"
 	if use opengl ; then
 		einfo "Building Molden OpenGL helper..."
-		emake -j1 "${args[@]}" moldenogl || die "moldenogl emake failed"
+		emake -j1 "$@" moldenogl || die "moldenogl emake failed"
 	fi
 }
 

Re: [gentoo-dev] Re: RFC: sh versionator.eclass

[George Shapovalov]

Tuesday, 2. October 2007, Roy Marples Ви написали:
> And here it is
-       if [[ "${FORTRANC}" = "gfortran" ]]; then
+       if [ "${FORTRANC}" = "gfortran" ]; then

You know, it is funny to see these lines after all those cries about how [ is 
evil and we should really never ever use it but rather always use [[ form :).

Oh, btw, does the compliant sh correctly process the most cited composition? :
[ -n $foo ] && [ -z $foo ] && echo "huh?"
(straight from devmanual, the primary reason why [ is  considered bad)

George
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: sh versionator.eclass

[Roy Marples]

On Tue, 2007-10-02 at 18:30 +0200, George Shapovalov wrote:
> Tuesday, 2. October 2007, Roy Marples Ви написали:
> > And here it is
> -       if [[ "${FORTRANC}" = "gfortran" ]]; then
> +       if [ "${FORTRANC}" = "gfortran" ]; then
> 
> You know, it is funny to see these lines after all those cries about how [ is 
> evil and we should really never ever use it but rather always use [[ form :).
> 
> Oh, btw, does the compliant sh correctly process the most cited composition? :
> [ -n $foo ] && [ -z $foo ] && echo "huh?"
> (straight from devmanual, the primary reason why [ is  considered bad)

bash and sh do the same thing
roy@uberlaptop ~ $ bash -c '[ -n $foo ] && [ -z $foo ] && echo "huh?"'
huh?
roy@uberlaptop ~ $ sh -c '[ -n $foo ] && [ -z $foo ] && echo "huh?"'
huh?

Maybe if you quoted properly it would work?
roy@uberlaptop ~ $ bash -c '[ -n "$foo" ] && [ -z "$foo" ] && echo
"huh?"'
roy@uberlaptop ~ $ sh -c '[ -n "$foo" ] && [ -z "$foo" ] && echo "huh?"'

By golly it does work!
And on both shells!
Amazing!

With [[ ]] you don't need to quote, which encourages people not to
bother learning when and when not to quote.

Regular readers of -dev will also notice a large amount of people not
quoting correctly, my view is that bash encourages this through the use
of [[ ]].

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: RFC: sh versionator.eclass

[Steve Long]

Roy Marples wrote:
> With [[ ]] you don't need to quote, which encourages people not to
> bother learning when and when not to quote.
>
Ugh, that is so untrue imo. In #bash most people don't know [[ and use [
without quoting, as well as leaving out quotes elsewhere. Which is why we
beat them over the head about quoting _all_ the time (!quotes in #bash [1])

> Regular readers of -dev will also notice a large amount of people not
> quoting correctly, my view is that bash encourages this through the use
> of [[ ]].
> 
A lot of those have been stuff like cd $S (when S could have spaces
according to where the tmp dir is located) and the like, ie stuff outside
[[. Honestly, [[ has got little to do with learning about quoting, since
the typical case where quoting is missing is when a path is passed to a
command. The thing to learn is that the shell expands everything before
passing it to a command, and that spaces will lead to two parameters where
you thought you had one, unless you use quotes. (ie cd "$S" )

Inside [[ is similar to assignment, in that it's down to the lex/parse (eg
a='  omg spaces!'; b='oh Noes! '$a; echo "$b"  # works fine -- but note
what happens when you echo $b with no quotes.) kojiro knows more about the
corner cases where quoting is needed in [[, but it _never_ shields you from
quoting issues outside tests, and you *will* be told about it if you paste
an unsafe loc in #bash. (We don't care if that's not the current problem as
you see it: if you're not quoting right, your scripts are worse than
useless, since they'll break when your users least expect it, for no
apparent reason, and you're nowhere to be found. People soon learn not to
paste unsafe expansions ;p and they get into the habit of always quoting.)

[1] USE MORE QUOTES! Read
http://bash-hackers.org/wiki/doku.php?id=syntax:words to understand why.
http://www.grymoire.com/Unix/Quote.html will tell you how. -- Optimally,
you should quote every parameter expansion ($foo).


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: RFC: sh versionator.eclass

[Roy Marples]

On Tue, 2007-10-02 at 19:37 +0100, Steve Long wrote:
> Roy Marples wrote:
> > With [[ ]] you don't need to quote, which encourages people not to
> > bother learning when and when not to quote.
> >
> Ugh, that is so untrue imo. In #bash most people don't know [[ and use [
> without quoting, as well as leaving out quotes elsewhere. Which is why we
> beat them over the head about quoting _all_ the time (!quotes in #bash [1])

You should always quote when using [ - the only exception you can ever
make is when using something like $? or $# as that is always a number.

> 
> > Regular readers of -dev will also notice a large amount of people not
> > quoting correctly, my view is that bash encourages this through the use
> > of [[ ]].
> > 
> A lot of those have been stuff like cd $S (when S could have spaces
> according to where the tmp dir is located) and the like, ie stuff outside
> [[. Honestly, [[ has got little to do with learning about quoting, since
> the typical case where quoting is missing is when a path is passed to a
> command. The thing to learn is that the shell expands everything before
> passing it to a command, and that spaces will lead to two parameters where
> you thought you had one, unless you use quotes. (ie cd "$S" )

Everything in shell IS a command with the exception of variable
assignment. Why do you think [ exist in /usr/bin?

Once you think "everything is a command" then quoting becomes a lot
easier. [[ ]] removes this concept.

> Inside [[ is similar to assignment, in that it's down to the lex/parse (eg
> a='  omg spaces!'; b='oh Noes! '$a; echo "$b"  # works fine -- but note
> what happens when you echo $b with no quotes.) kojiro knows more about the
> corner cases where quoting is needed in [[, but it _never_ shields you from
> quoting issues outside tests, and you *will* be told about it if you paste
> an unsafe loc in #bash. (We don't care if that's not the current problem as
> you see it: if you're not quoting right, your scripts are worse than
> useless, since they'll break when your users least expect it, for no
> apparent reason, and you're nowhere to be found. People soon learn not to
> paste unsafe expansions ;p and they get into the habit of always quoting.)
> 
> [1] USE MORE QUOTES! Read
> http://bash-hackers.org/wiki/doku.php?id=syntax:words to understand why.
> http://www.grymoire.com/Unix/Quote.html will tell you how. -- Optimally,
> you should quote every parameter expansion ($foo).

So in other words, [ ] always needs quotes whereas [[ ]] normally
doesn't but could need quotes in corner cases.

I know which I'd prefer - certainty over uncertainty.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Re: RFC: sh versionator.eclass

[Steve Long]

Roy Marples wrote:

> On Tue, 2007-10-02 at 19:37 +0100, Steve Long wrote:
>> Roy Marples wrote:
>> > With [[ ]] you don't need to quote, which encourages people not to
>> > bother learning when and when not to quote.
>> >
>> Ugh, that is so untrue imo. In #bash most people don't know [[ and use [
>> without quoting, as well as leaving out quotes elsewhere. Which is why we
>> beat them over the head about quoting _all_ the time (!quotes in #bash
>> [1])
> 
> You should always quote when using [ - the only exception you can ever
> make is when using something like $? or $# as that is always a number.
>
Indeed.

>> 
>> > Regular readers of -dev will also notice a large amount of people not
>> > quoting correctly, my view is that bash encourages this through the use
>> > of [[ ]].
>> > 
>> A lot of those have been stuff like cd $S (when S could have spaces
>> according to where the tmp dir is located) and the like, ie stuff outside
>> [[. Honestly, [[ has got little to do with learning about quoting, since
>> the typical case where quoting is missing is when a path is passed to a
>> command. The thing to learn is that the shell expands everything before
>> passing it to a command, and that spaces will lead to two parameters
>> where you thought you had one, unless you use quotes. (ie cd "$S" )
> 
> Everything in shell IS a command with the exception of variable
> assignment. Why do you think [ exist in /usr/bin?
>
Yes I know, it's the same reason greycat will often use test -e blah &&
blahBlah to show where the command comes from. (Which is why you use 'help
test' to see what tests are actually available.) It doesn't change the fact
that quoting issues show up outside [[, and you need to be aware of them in
bash just as much as in sh.

IMO the real reason you have such an issue with quoting is the redundant
braces which are Gentoo house style; too many newbie scripters think that
cd ${S} is safe when it should be cd "${S}" or more simply cd "$S". I don't
buy the legibility argument since most people use syntax highlighting. It
just sets the parser up for a non-event (yes I am *that* fussy about
cycles.) My suspicion is that it came from echo "${RD}message$NO"

> Once you think "everything is a command" then quoting becomes a lot
> easier. [[ ]] removes this concept.
>
Yeah but the point is you learn about quoting for every other command, or
you simply won't be writing reusable scripts (assuming they actually work
for you at all.)

>> Inside [[ is similar to assignment, in that it's down to the lex/parse
>> (eg
>> a='  omg spaces!'; b='oh Noes! '$a; echo "$b"  # works fine -- but note
>> what happens when you echo $b with no quotes.) kojiro knows more about
>> the corner cases where quoting is needed in [[, but it _never_ shields
>> you from quoting issues outside tests, and you *will* be told about it if
>> you paste an unsafe loc in #bash. (We don't care if that's not the
>> current problem as you see it: if you're not quoting right, your scripts
>> are worse than useless, since they'll break when your users least expect
>> it, for no apparent reason, and you're nowhere to be found. People soon
>> learn not to paste unsafe expansions ;p and they get into the habit of
>> always quoting.)
>> 
>> [1] USE MORE QUOTES! Read
>> http://bash-hackers.org/wiki/doku.php?id=syntax:words to understand why.
>> http://www.grymoire.com/Unix/Quote.html will tell you how. -- Optimally,
>> you should quote every parameter expansion ($foo).
> 
> So in other words, [ ] always needs quotes whereas [[ ]] normally
> doesn't but could need quotes in corner cases.
> 
> I know which I'd prefer - certainty over uncertainty.
> 
Well to be absolutely honest I've never actually needed them, and I only
mentioned it for completeness as kojiro said there was some case (involving
array expansion iirc, so sh wouldn't even be able to express the metaphor,
let alone get in a twist about it.) It was definitely not the run-of-the
mill issue. I still would not give up pattern and regex matching (to name
my top two) in [[, and definitely not for the trade-down to sh, where you'd
be doing all kinds of odd syntax to get round the limitations of the
lowest-common denominator.

I'd prefer powerful, expressive tools which don't lock me into a proprietary
solution. A GNU userland seems a small price to pay, and we're only talking
about one app here, not the whole userland. (I had actually thought the
point of Gentoo/FBSD was to use the BSD kernel with Gentoo/GNU tools. It
seems odd that the tail is now wagging the dog, so to speak, much as I like
the idea. Can I ask why you are so resistent to Gentoo/FBSD using GNU
tools?)

I still don't see the use case, sorry. If an embedded system can't support
bash (and even if it could tbh) it'd be a fool who compiled on the target
imo. (I wouldn't put gcc on an embedded system for a start, but then I'm
old ;) And bash works everywhere else afaict. Who exactly does "freeing the
tree" help, and how is it such a great inconvenience for those users to
install bash?

Wrt choice, what about the developer choice to use a fully featured shell so
they don't have to write 5 loc where 1 would do, or mess around with
error-prone evals, and set which allows only 1 array etc? (I know you can
handle all kinds of weird quoting in eval, but it makes my head hurt, and I
would *hate* to maintain that kind of code.) Leave alone the choice not to
fix it, since it patently isn't broken.

One last point on arrays: it's true that you can pass an array to a
command/function with foo "${a[@]}" but there's nothing to stop an eclass
saying "we reference arrays bar baz and qux which you should populate
before using this eclass/function," and indeed accessing all three arrays
in the same function. The single case just isn't such a performance hit
compared to the whole configure/make cycle, and I'd imagine the locality is
preferred for maintenance.

Search a list of 250 pkgs repeatedly with inList "$pkg" "${list[@]}" and you
start to notice it, though ;)


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: RFC: sh versionator.eclass

[Roy Marples]

On Tue, 2007-10-02 at 23:18 +0100, Steve Long wrote:
> Roy Marples wrote:
> > Everything in shell IS a command with the exception of variable
> > assignment. Why do you think [ exist in /usr/bin?
> >
> Yes I know, it's the same reason greycat will often use test -e blah &&
> blahBlah to show where the command comes from. (Which is why you use 'help
> test' to see what tests are actually available.) It doesn't change the fact
> that quoting issues show up outside [[, and you need to be aware of them in
> bash just as much as in sh.

I agree.
My argument is that [[ encourages no quoting, hence it showing up more
As [ forces people to quote correctly, it should show up less outside of
[ or [[

> IMO the real reason you have such an issue with quoting is the redundant
> braces which are Gentoo house style; too many newbie scripters think that
> cd ${S} is safe when it should be cd "${S}" or more simply cd "$S". I don't
> buy the legibility argument since most people use syntax highlighting. It
> just sets the parser up for a non-event (yes I am *that* fussy about
> cycles.) My suspicion is that it came from echo "${RD}message$NO"

Not helped by unpack ${A} which should not be quoted if >1 thing to to
unpack.

> 
> > Once you think "everything is a command" then quoting becomes a lot
> > easier. [[ ]] removes this concept.
> >
> Yeah but the point is you learn about quoting for every other command, or
> you simply won't be writing reusable scripts (assuming they actually work
> for you at all.)

Why not learn about quoting for everything?
As it's so important, why should [[ be an exception? And as a prior
email claimed, [[ sometimes needs quoting anyway just to muddy things
even more.

> > So in other words, [ ] always needs quotes whereas [[ ]] normally
> > doesn't but could need quotes in corner cases.
> > 
> > I know which I'd prefer - certainty over uncertainty.
> > 
> Well to be absolutely honest I've never actually needed them, and I only
> mentioned it for completeness as kojiro said there was some case (involving
> array expansion iirc, so sh wouldn't even be able to express the metaphor,
> let alone get in a twist about it.) It was definitely not the run-of-the
> mill issue. I still would not give up pattern and regex matching (to name
> my top two) in [[, and definitely not for the trade-down to sh, where you'd
> be doing all kinds of odd syntax to get round the limitations of the
> lowest-common denominator.

Show me an ebuild that uses pattern and/or regex matching please?
I don't think you're giving up all that much.

[ ... ]

This is the posix sh vs bash for eclasses thread, GNU userland vs BSD
userland is next months flamewar ;)

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: RFC: sh versionator.eclass

[Ryan Hill]

Steve Long wrote:
> IMO the real reason you have such an issue with quoting is the redundant
> braces which are Gentoo house style; too many newbie scripters think that
> cd ${S} is safe when it should be cd "${S}" or more simply cd "$S". I don't
> buy the legibility argument since most people use syntax highlighting. It
> just sets the parser up for a non-event (yes I am *that* fussy about
> cycles.) My suspicion is that it came from echo "${RD}message$NO"

Or because the unbraced case looks like ass.

-- 
                  fonts / wxWindows / gcc-porting / treecleaners
  9B81 6C9F E791 83BB 3AB3  5B2D E625 A073 8379 37E8 (0x837937E8)

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: sh versionator.eclass

[Roy Marples]

On Tue, 2007-10-02 at 19:29 -0600, Ryan Hill wrote:
> Steve Long wrote:
> > IMO the real reason you have such an issue with quoting is the redundant
> > braces which are Gentoo house style; too many newbie scripters think that
> > cd ${S} is safe when it should be cd "${S}" or more simply cd "$S". I don't
> > buy the legibility argument since most people use syntax highlighting. It
> > just sets the parser up for a non-event (yes I am *that* fussy about
> > cycles.) My suspicion is that it came from echo "${RD}message$NO"
> 
> Or because the unbraced case looks like ass.

You also need braces for ${#FOO} and other such parameter expansion.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: sh versionator.eclass

[Mike Frysinger]

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

On Tuesday 02 October 2007, George Shapovalov wrote:
> Tuesday, 2. October 2007, Roy Marples Ви написали:
> > And here it is
>
> -       if [[ "${FORTRANC}" = "gfortran" ]]; then
> +       if [ "${FORTRANC}" = "gfortran" ]; then
>
> You know, it is funny to see these lines after all those cries about how [
> is evil and we should really never ever use it but rather always use [[
> form :).
>
> Oh, btw, does the compliant sh correctly process the most cited
> composition? : [ -n $foo ] && [ -z $foo ] && echo "huh?"
> (straight from devmanual, the primary reason why [ is  considered bad)

[...] will crap a brick if foo expands to multiple arguments which is why 
[[...]] is preferred ... it'll do the sane thing and work correctly 
regardless
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Re: RFC: sh versionator.eclass

[Roy Marples]

On Sun, 2007-10-07 at 01:09 -0400, Mike Frysinger wrote:
> On Tuesday 02 October 2007, George Shapovalov wrote:
> > Tuesday, 2. October 2007, Roy Marples Ви написали:
> > > And here it is
> >
> > -       if [[ "${FORTRANC}" = "gfortran" ]]; then
> > +       if [ "${FORTRANC}" = "gfortran" ]; then
> >
> > You know, it is funny to see these lines after all those cries about how [
> > is evil and we should really never ever use it but rather always use [[
> > form :).
> >
> > Oh, btw, does the compliant sh correctly process the most cited
> > composition? : [ -n $foo ] && [ -z $foo ] && echo "huh?"
> > (straight from devmanual, the primary reason why [ is  considered bad)
> 
> [...] will crap a brick if foo expands to multiple arguments

Only if unquoted.

>  which is why 
> [[...]] is preferred ... it'll do the sane thing and work correctly 

Which encourages developers not to quote in my view.

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: sh versionator.eclass

[Mike Frysinger]

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

On Sunday 07 October 2007, Roy Marples wrote:
> On Sun, 2007-10-07 at 01:09 -0400, Mike Frysinger wrote:
> > On Tuesday 02 October 2007, George Shapovalov wrote:
> > > Tuesday, 2. October 2007, Roy Marples Ви написали:
> > > > And here it is
> > >
> > > -       if [[ "${FORTRANC}" = "gfortran" ]]; then
> > > +       if [ "${FORTRANC}" = "gfortran" ]; then
> > >
> > > You know, it is funny to see these lines after all those cries about
> > > how [ is evil and we should really never ever use it but rather always
> > > use [[ form :).
> > >
> > > Oh, btw, does the compliant sh correctly process the most cited
> > > composition? : [ -n $foo ] && [ -z $foo ] && echo "huh?"
> > > (straight from devmanual, the primary reason why [ is  considered bad)
> >
> > [...] will crap a brick if foo expands to multiple arguments
>
> Only if unquoted.
>
> >  which is why
> > [[...]] is preferred ... it'll do the sane thing and work correctly
>
> Which encourages developers not to quote in my view.

addressing one issue (quoting) while ignoring others (extended syntax) leads 
to crappy inconsistencies.  if the standard you want (POSIX) cant do it all, 
then nitpicking details is a waste of time.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Re: RFC: sh versionator.eclass

[Alex Tarkovsky]

On 10/2/07, Roy Marples <uberlord@gentoo.org> wrote:
> > I accept the argument for initscripts, since an embedded system is not
> > likely to have bash. But for compile-time (which shouldn't happen on an
> > embedded target) there simply isn't any real benefit to end-users that I
> > can see.
>
> The benefit is that our portage tree uses an accepted standardised
> syntax. bash is just a standard to itself.

How many Gentoo devs are familiar with Bash syntax? All of them.

How many are familiar with the more obscure POSIX sh syntax? A few.

Migrating Gentoo's init scripts, eclasses, and ebuilds -- though not
necessarily all of them -- over to POSIX sh syntax requires all Gentoo
devs to know the rules of sh just to be able to continue contributing
to Gentoo without breaking stuff. This will also put off more casual
contributors who work through proxy maintainerships, Sunrise, and
Bugzilla.

Then you'll need to ensure that all official documentation accomodates
sh syntax, including the ebuild quiz. (And what about the poor folks
at the Gentoo wiki?)

Add these concerns to the technical objections already raised, and the
touted benefits of your proposal are overwhelmed by the amount of work
it would create and the disruption it will cause to Gentoo
development.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: sh versionator.eclass

[Yuri Gagarin]

On 10/2/07, Alex Tarkovsky <alextarkovsky@gmail.com> wrote:
> On 10/2/07, Roy Marples <uberlord@gentoo.org> wrote:
> > > I accept the argument for initscripts, since an embedded system is not
> > > likely to have bash. But for compile-time (which shouldn't happen on an
> > > embedded target) there simply isn't any real benefit to end-users that I
> > > can see.
> >
> > The benefit is that our portage tree uses an accepted standardised
> > syntax. bash is just a standard to itself.
>
> How many Gentoo devs are familiar with Bash syntax? All of them.
>
> How many are familiar with the more obscure POSIX sh syntax? A few.
>
> Migrating Gentoo's init scripts, eclasses, and ebuilds -- though not
> necessarily all of them -- over to POSIX sh syntax requires all Gentoo
> devs to know the rules of sh just to be able to continue contributing
> to Gentoo without breaking stuff. This will also put off more casual
> contributors who work through proxy maintainerships, Sunrise, and
> Bugzilla.
>
> Then you'll need to ensure that all official documentation accomodates
> sh syntax, including the ebuild quiz. (And what about the poor folks
> at the Gentoo wiki?)
>
> Add these concerns to the technical objections already raised, and the
> touted benefits of your proposal are overwhelmed by the amount of work
> it would create and the disruption it will cause to Gentoo
> development.

And the pain it'll cause users who maintain their own ebuilds/scripts
locally. But if no consideration is given by Roy's proposal to the
concerns above, then the users, per usual, will most certainly be
overlooked.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: sh versionator.eclass

[Natanael Copa]

On Tue, 2007-10-02 at 09:29 +0200, Fabian Groffen wrote:
> On 01-10-2007 22:59:40 +0100, Roy Marples wrote:
> > I would like to propse a new versionator.eclass for consideration (attached).
> > 
> > This version, I believe, is more readable and maintainable then the one 
> > currently in portage. It also uses a lot less code and has the bonus of being 
> > pure sh.
> 
> What is your rationale to say that "pure sh" is a "bonus"?  Especially
> given the environment this is used in as ferdy already pointed out?
> 
> I personally like consistency.  So if we use bash in ebuilds, then I'd
> like to use bash in eclasses too.  I'm interested in your motivation to
> make this eclass "pure sh", whatever that may mean.

Code is GPL. It can be reused. shell code that can compare versions is
very attarctive. It can be used to write shellscripts that removes all
tbz2 but the last version. It can be re-used in runtime-only
environemnts. It can be reused on non-gentoo hosts hosting
distfiles/tbz2. Or it can be reused in a binary only package manager
like http://apk-tools.sf.net (yep, i reinveted the wheel there, just
because my uclibc runtime environments dont include python)

If it make sense to POSIX compliant shell code in any eclass, it would
be version handling code.

Thanks Roy!

-nc


-- 
gentoo-dev@gentoo.org mailing list