[gentoo-dev] RFC: l10n.eclass

[gentoo-dev] RFC: l10n.eclass

[Ben de Groot]

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

Today I would like to present to you my proposal for a new eclass with
helper functions for treating localizations: l10n.eclass (see the
attached file or [1]). Its functionality can be used in other eclasses
(such as qt4-r2 and cmake-utils) as well as directly in ebuilds.

In order to keep the code simple, and prevent double loops and extra
variables (such as currently used in the media-video/smplayer ebuild),
I am proposing that we should add any missing long-form locales to
profiles/desc/linguas.desc (e.g. 'de_DE' in addition to short 'de').
This also means that users may have to expand their LINGUAS setting in
make.conf (e.g. LINGUAS="de en" -> LINGUAS="de de_DE en en_US") to
cover the different variants used in packages.

If you have any comments, spot any mistakes, or have proposals for
improvement, I would love to hear it! I would especially love from
maintainers of complicated packages such as libreoffice-l10n, if there
is any additional functionality that we could include in this eclass
to make their job simpler.

1: https://gitorious.org/gentoo-qt/qt/blobs/master/eclass/l10n.eclass
-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

[-- Attachment #2: l10n.eclass --]
[-- Type: application/octet-stream, Size: 3917 bytes --]

# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: l10n.eclass
# @MAINTAINER:
# Ben de Groot <yngwin@gentoo.org>
# @BLURB: convenience functions to handle localizations
# @DESCRIPTION:
# The l10n (localization) eclass offers a number of functions to more
# conveniently handle localizations (translations) offered by packages.
# These are meant to prevent code duplication for such boring tasks as
# determining the cross-section between the user's set LINGUAS and what
# is offered by the package; and generating the right list of linguas_*
# USE flags.

# @ECLASS-VARIABLE: PLOCALES
# @DEFAULT_UNSET
# @DESCRIPTION:
# Variable listing the locales for which localizations are offered by
# the package. Check profiles/desc/linguas.desc to see if the locales
# are listed there. Add any missing ones there.
#
# Example: PLOCALES="cy de el_GR en_US pt_BR vi zh_CN"

# @ECLASS-VARIABLE: PLOCALE_BACKUP
# @DEFAULT_UNSET
# @DESCRIPTION:
# In some cases the package fails when none of the offered PLOCALES are
# selected by the user. In that case this variable should be set to a
# default locale (usually 'en' or 'en_US') as backup.
#
# Example: PLOCALE_BACKUP="en_US"

# Add linguas useflags
[[ -n "${PLOCALES}" ]] && IUSE+=" $(printf 'linguas_%s ' ${PLOCALES})"

# @FUNCTION: l10n_for_each_locale_do
# @USAGE: <function>
# @DESCRIPTION:
# Convenience function for processing localizations. The parameter should
# be a function (defined in the consuming eclass or ebuild) which takes
# an individual localization as (last) parameter.
#
# Example: l10n_for_each_locale_do install_locale
l10n_for_each_locale_do() {
	local xlocs=
	xlocs=$(l10n_get_linguas_crosssection)
	if [[ -n "${xlocs}" ]]; then
		local x
		for x in ${xlocs}; do
			${@} ${x} || die "failed to process ${x} locale"
		done
	fi
}

# @FUNCTION: l10n_for_each_unselected_locale_do
# @USAGE: <function>
# @DESCRIPTION:
# Complementary to l10n_for_each_locale_do, this function will process
# locales that are not selected. This could be used for example to remove
# locales from a Makefile, to prevent them from being built needlessly.
l10n_for_each_unselected_locale_do() {
	local o= x=
	o=$(join -v 1 <(echo "${PLOCALES// /$'\n'}") <(echo "${LINGUAS// /$'\n'}") )
	o=${o//$'\n'/' '}
	einfo "Unselected locales are: ${o}"
	if [[ -n "${o}" ]]; then
		for x in ${o}; do
			${@} ${x} || die "failed to process unselected ${x} locale"
		done
	fi
}

# @FUNCTION: l10n_find_plocales_changes
# @USAGE: <translations dir> <filename pre pattern> <filename post pattern>
# @DESCRIPTION:
# Ebuild maintenance helper function to find changes in package offered
# locales when doing a version bump. This could be added for example to
# src_prepare
#
# Example: l10n_find_plocales_changes "${S}/src/translations" "${PN}_" '.ts'
l10n_find_plocales_changes() {
	[[ $# -ne 3 ]] && die "Exactly 3 arguments are needed!"
	einfo "Looking in ${1} for new locales ..."
	pushd "${1}" >/dev/null || die "Cannot access ${1}"
	local current= x=
	for x in ${2}*${3} ; do
		x=${x#"${2}"}
		x=${x%"${3}"}
		current+="${x} "
	done
	popd >/dev/null
	if [[ ${PLOCALES} != ${current%[[:space:]]} ]] ; then
		einfo "There are changes in locales! This ebuild should be updated to:"
		einfo "PLOCALES=\"${current%[[:space:]]}\""
	fi
}

# @FUNCTION: l10n_get_linguas_crosssection
# @DESCRIPTION:
# Determine the cross-section of user-set LINGUAS and the locales which
# the package offers (listed in PLOCALES), and return them. In case no
# locales are selected, fall back on PLOCALE_BACKUP. This function is
# normally used internally in this eclass, not by l10n.eclass consumers.
l10n_get_linguas_crosssection() {
	local lang= loc= xloc=
	for lang in ${LINGUAS}; do
		for loc in ${PLOCALES}; do
			[[ ${lang} == ${loc} ]] && xloc+="${loc} "
		done
	done
	xloc=${xloc:-$PLOCALE_BACKUP}
	printf "%s" "${xloc}"
}

Re: [gentoo-dev] RFC: l10n.eclass

[Ralph Sennhauser]

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

On Thu, 19 Jul 2012 14:45:39 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> Today I would like to present to you my proposal for a new eclass with
> helper functions for treating localizations: l10n.eclass (see the
> attached file or [1]). Its functionality can be used in other eclasses
> (such as qt4-r2 and cmake-utils) as well as directly in ebuilds.
> 
> In order to keep the code simple, and prevent double loops and extra
> variables (such as currently used in the media-video/smplayer ebuild),
> I am proposing that we should add any missing long-form locales to
> profiles/desc/linguas.desc (e.g. 'de_DE' in addition to short 'de').
> This also means that users may have to expand their LINGUAS setting in
> make.conf (e.g. LINGUAS="de en" -> LINGUAS="de de_DE en en_US") to
> cover the different variants used in packages.
> 
> If you have any comments, spot any mistakes, or have proposals for
> improvement, I would love to hear it! I would especially love from
> maintainers of complicated packages such as libreoffice-l10n, if there
> is any additional functionality that we could include in this eclass
> to make their job simpler.
> 
> 1: https://gitorious.org/gentoo-qt/qt/blobs/master/eclass/l10n.eclass

I assume the P in PLOCALS stands for package. Not that obvious if you
ask me. L10N_LOCALS would at least tell me which eclass this variable
belongs to.

Instead of using LINGUAS you should make use of the use function to get
your cross sections. ie.

for locale in ${PLOCALES}; do
  if use linguas_${locale}; then
    enabled_locales+=" ${locale}"
  else
    disabled_locales+=" ${locale}"
  fi
done

First, this is guaranteed by PMS and so independent of package manager
and second, you do not have to care about locales in LINGUAS which are
invalid for the package. Could be that Portage re-exports a sanitized
LINGUAS tough, but I doubt it.

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

Re: [gentoo-dev] RFC: l10n.eclass

[Ben de Groot]

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

On 19 July 2012 21:14, Ralph Sennhauser <sera@gentoo.org> wrote:
>
> I assume the P in PLOCALS stands for package. Not that obvious if you
> ask me. L10N_LOCALS would at least tell me which eclass this variable
> belongs to.

Yes, as P is widely used to refer to the package. I wanted something to
reflect that these are the locales offered by the package.

> Instead of using LINGUAS you should make use of the use function to get
> your cross sections. ie.
>
> for locale in ${PLOCALES}; do
>   if use linguas_${locale}; then
>     enabled_locales+=" ${locale}"
>   else
>     disabled_locales+=" ${locale}"
>   fi
> done
>
> First, this is guaranteed by PMS and so independent of package manager
> and second, you do not have to care about locales in LINGUAS which are
> invalid for the package. Could be that Portage re-exports a sanitized
> LINGUAS tough, but I doubt it.

This is a good suggestion, as it makes things simpler and more along
expected lines.

I got a few more suggestions on IRC, and I have updated the eclass
accordingly. Please check the attached new version, also available at
https://gitorious.org/gentoo-qt/qt/blobs/master/eclass/l10n.eclass

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

[-- Attachment #2: l10n.eclass --]
[-- Type: application/octet-stream, Size: 4059 bytes --]

# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: l10n.eclass
# @MAINTAINER:
# Ben de Groot <yngwin@gentoo.org>
# @BLURB: convenience functions to handle localizations
# @DESCRIPTION:
# The l10n (localization) eclass offers a number of functions to more
# conveniently handle localizations (translations) offered by packages.
# These are meant to prevent code duplication for such boring tasks as
# determining the cross-section between the user's set LINGUAS and what
# is offered by the package; and generating the right list of linguas_*
# USE flags.

# @ECLASS-VARIABLE: PLOCALES
# @DEFAULT_UNSET
# @DESCRIPTION:
# Variable listing the locales for which localizations are offered by
# the package. Check profiles/desc/linguas.desc to see if the locales
# are listed there. Add any missing ones there.
#
# Example: PLOCALES="cy de el_GR en_US pt_BR vi zh_CN"

# @ECLASS-VARIABLE: PLOCALE_BACKUP
# @DEFAULT_UNSET
# @DESCRIPTION:
# In some cases the package fails when none of the offered PLOCALES are
# selected by the user. In that case this variable should be set to a
# default locale (usually 'en' or 'en_US') as backup.
#
# Example: PLOCALE_BACKUP="en_US"

# Add linguas useflags
if [[ -n "${PLOCALES}" ]]; then
	for u in ${PLOCALES}; do
		IUSE+=" linguas_${u}"
	done
fi

# @FUNCTION: l10n_for_each_locale_do
# @USAGE: <function>
# @DESCRIPTION:
# Convenience function for processing localizations. The parameter should
# be a function (defined in the consuming eclass or ebuild) which takes
# an individual localization as (last) parameter.
#
# Example: l10n_for_each_locale_do install_locale
l10n_for_each_locale_do() {
	local locs x
	locs=$(l10n_get_locales)
	if [[ -n "${locs}" ]]; then
		for x in ${locs}; do
			${@} ${x} || die "failed to process enabled ${x} locale"
		done
	fi
}

# @FUNCTION: l10n_for_each_disabled_locale_do
# @USAGE: <function>
# @DESCRIPTION:
# Complementary to l10n_for_each_locale_do, this function will process
# locales that are disabled. This could be used for example to remove
# locales from a Makefile, to prevent them from being built needlessly.
l10n_for_each_disabled_locale_do() {
	local locs x
	locs=$(l10n_get_locales disabled)
	if [[ -n "${locs}" ]]; then
		for x in ${locs}; do
			${@} ${x} || die "failed to process disabled ${x} locale"
		done
	fi
}

# @FUNCTION: l10n_find_plocales_changes
# @USAGE: <translations dir> <filename pre pattern> <filename post pattern>
# @DESCRIPTION:
# Ebuild maintenance helper function to find changes in package offered
# locales when doing a version bump. This could be added for example to
# src_prepare
#
# Example: l10n_find_plocales_changes "${S}/src/translations" "${PN}_" '.ts'
l10n_find_plocales_changes() {
	[[ $# -ne 3 ]] && die "Exactly 3 arguments are needed!"
	einfo "Looking in ${1} for new locales ..."
	pushd "${1}" >/dev/null || die "Cannot access ${1}"
	local current= x=
	for x in ${2}*${3} ; do
		x=${x#"${2}"}
		x=${x%"${3}"}
		current+="${x} "
	done
	popd >/dev/null
	if [[ ${PLOCALES} != ${current%[[:space:]]} ]] ; then
		einfo "There are changes in locales! This ebuild should be updated to:"
		einfo "PLOCALES=\"${current%[[:space:]]}\""
	else
		einfo "Done"
	fi
}

# @FUNCTION: l10n_get_locales
# @USAGE: [disabled]
# @DESCRIPTION:
# Determine which LINGUAS USE flags the user has enabled that are offered
# by the package, as listed in PLOCALES, and return them. In case no
# locales are selected, fall back on PLOCALE_BACKUP. When the disabled
# argument is given, return the disabled useflags instead of the enabled
# ones. This function is normally used internally in this eclass, not by
# l10n.eclass consumers.
l10n_get_locales() {
	local disabled_locales enabled_locales loc locs
	for loc in ${PLOCALES}; do
		if use linguas_${loc}; then
			enabled_locales+="${loc} "
		else
			disabled_locales+="${loc} "
		fi
	done
	if [[ ${1} == disabled ]]; then
		locs=${disabled_locales}
	else
		locs=${enabled_locales:-$PLOCALE_BACKUP}
	fi
	printf "%s" "${locs}"
}

Re: [gentoo-dev] RFC: l10n.eclass

[Ralph Sennhauser]

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

On Thu, 19 Jul 2012 23:37:32 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> I got a few more suggestions on IRC, and I have updated the eclass
> accordingly. Please check the attached new version, also available at
> https://gitorious.org/gentoo-qt/qt/blobs/master/eclass/l10n.eclass

Pseudo inlining

> # Add linguas useflags
> if [[ -n "${PLOCALES}" ]]; then
> 	for u in ${PLOCALES}; do
> 		IUSE+=" linguas_${u}"
> 	done
> fi

no need to guard the loop against empty $PLOCALES.

> l10n_for_each_locale_do() {
> 	local locs x
> 	locs=$(l10n_get_locales)
> 	if [[ -n "${locs}" ]]; then
> 		for x in ${locs}; do
> 			${@} ${x} || die "failed to process enabled
> ${x} locale" done
> 	fi
> }

same here, no guarding required and "${@}" should be quoted as it may
contain args with spaces. Also in l10n_for_each_disabled_locale_do.

> # ones. This function is normally used internally in this eclass, not
> by # l10n.eclass consumers.
> l10n_get_locales() {

I'd mark this function @INTERNAL then, at least until someone can
presents a use case.
If you are sufficiently sure this function shouldn't be used by
consumers you could remove the function in favour of 'use linguas_${x}
|| continue' in l10n_for_each_locale_do resp 'use linguas_${x}
&& continue' in l10n_for_each_disabled_locale_do.

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

Re: [gentoo-dev] RFC: l10n.eclass

[Ben de Groot]

On 20 July 2012 15:33, Ralph Sennhauser <sera@gentoo.org> wrote:
> On Thu, 19 Jul 2012 23:37:32 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>
>> I got a few more suggestions on IRC, and I have updated the eclass
>> accordingly. Please check the attached new version, also available at
>> https://gitorious.org/gentoo-qt/qt/blobs/master/eclass/l10n.eclass
>
> Pseudo inlining
>
>> # Add linguas useflags
>> if [[ -n "${PLOCALES}" ]]; then
>>       for u in ${PLOCALES}; do
>>               IUSE+=" linguas_${u}"
>>       done
>> fi
>
> no need to guard the loop against empty $PLOCALES.
>
>> l10n_for_each_locale_do() {
>>       local locs x
>>       locs=$(l10n_get_locales)
>>       if [[ -n "${locs}" ]]; then
>>               for x in ${locs}; do
>>                       ${@} ${x} || die "failed to process enabled
>> ${x} locale" done
>>       fi
>> }
>
> same here, no guarding required and "${@}" should be quoted as it may
> contain args with spaces. Also in l10n_for_each_disabled_locale_do.

Okay, I will make those changes.

>> # ones. This function is normally used internally in this eclass, not
>> by # l10n.eclass consumers.
>> l10n_get_locales() {
>
> I'd mark this function @INTERNAL then, at least until someone can
> presents a use case.
> If you are sufficiently sure this function shouldn't be used by
> consumers you could remove the function

There are use cases, e.g. net-im/qtwitter-0.10.0-r1 for which I have
an editted -r10 revision in my dev overlay. I'm sure it could be handled
with l10n_for_each_locale_do, but the migration is more straight-forward
by simply using l10n_get_locales in this case.

This is why I worded it "normally" instead of "only". Maybe the wording
could be improved?

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] RFC: l10n.eclass

[Ralph Sennhauser]

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

On Mon, 23 Jul 2012 20:29:44 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> >> # ones. This function is normally used internally in this eclass,
> >> not by # l10n.eclass consumers.
> >> l10n_get_locales() {  
> >
> > I'd mark this function @INTERNAL then, at least until someone can
> > presents a use case.
> > If you are sufficiently sure this function shouldn't be used by
> > consumers you could remove the function  
> 
> There are use cases, e.g. net-im/qtwitter-0.10.0-r1 for which I have
> an editted -r10 revision in my dev overlay. I'm sure it could be
> handled with l10n_for_each_locale_do, but the migration is more
> straight-forward by simply using l10n_get_locales in this case.
> 
> This is why I worded it "normally" instead of "only". Maybe the
> wording could be improved?

The primary concern should be expressiveness. That said, qttwitter
looks like a good example use case. You have convinced me.

src_configure() {
  qmake4 PREFIX="/usr" LANGS="$(l10n_get_locales)"
}

Maybe l10n_get_enabled_locales would read even more natural here?

Either way I'd drop the internal entirely as it also provides a simple
way to "sanitize" LINGUAS without relying on the package manager. ie.
setting 'LINGUAS="$(l10n_get_locales)"' in an ebuild would enable the
possible EAPI 5 behaviour described later in this thread, which would
allow direct use of LINGUAS. The only difference being the backup
locale.

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

Re: [gentoo-dev] RFC: l10n.eclass

[Ciaran McCreesh]

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

On Thu, 19 Jul 2012 15:14:22 +0200
Ralph Sennhauser <sera@gentoo.org> wrote:
> First, this is guaranteed by PMS and so independent of package manager
> and second, you do not have to care about locales in LINGUAS which are
> invalid for the package. Could be that Portage re-exports a sanitized
> LINGUAS tough, but I doubt it.

With EAPI 5, LINGUAS will be intersected with IUSE (but with the
linguas_ bit stripped off).

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: l10n.eclass

[Zac Medico]

On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
> Could be that Portage re-exports a sanitized
> LINGUAS tough, but I doubt it.

Portage does sanitize it if there are any linguas_* flags in IUSE,
otherwise it lets the variable pass through without sanitizing it.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: l10n.eclass

[Mike Gilbert]

On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico@gentoo.org> wrote:
> On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
>> Could be that Portage re-exports a sanitized
>> LINGUAS tough, but I doubt it.
>
> Portage does sanitize it if there are any linguas_* flags in IUSE,
> otherwise it lets the variable pass through without sanitizing it.

That's good; we definitely don't want to "sanitize" it if there are no
linuguas_* flags in IUSE. This would break LINUGUAS support for many
autotools/gettext based packages, where the autotools code parses
LINGUAS directly and the ebuild does nothing with it.

Re: [gentoo-dev] RFC: l10n.eclass

[Ciaran McCreesh]

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

On Thu, 19 Jul 2012 18:34:41 -0400
Mike Gilbert <floppym@gentoo.org> wrote:
> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico@gentoo.org>
> wrote:
> > On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
> >> Could be that Portage re-exports a sanitized
> >> LINGUAS tough, but I doubt it.
> >
> > Portage does sanitize it if there are any linguas_* flags in IUSE,
> > otherwise it lets the variable pass through without sanitizing it.
> 
> That's good; we definitely don't want to "sanitize" it if there are no
> linuguas_* flags in IUSE. This would break LINUGUAS support for many
> autotools/gettext based packages, where the autotools code parses
> LINGUAS directly and the ebuild does nothing with it.

If there aren't any linguas_* flags in IUSE, LINGUAS should be empty,
and will be in future EAPIs. Without that, USE dependencies on
USE_EXPAND variables don't work.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: l10n.eclass

[Mike Gilbert]

On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Thu, 19 Jul 2012 18:34:41 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
>> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico@gentoo.org>
>> wrote:
>> > On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
>> >> Could be that Portage re-exports a sanitized
>> >> LINGUAS tough, but I doubt it.
>> >
>> > Portage does sanitize it if there are any linguas_* flags in IUSE,
>> > otherwise it lets the variable pass through without sanitizing it.
>>
>> That's good; we definitely don't want to "sanitize" it if there are no
>> linuguas_* flags in IUSE. This would break LINUGUAS support for many
>> autotools/gettext based packages, where the autotools code parses
>> LINGUAS directly and the ebuild does nothing with it.
>
> If there aren't any linguas_* flags in IUSE, LINGUAS should be empty,
> and will be in future EAPIs. Without that, USE dependencies on
> USE_EXPAND variables don't work.

How do you figure that?

The current portage behavior works well enough; if linugas_* is in
IUSE, LINGUAS is treated as a USE_EXPAND, and use-deps should work
fine.

Otherwise, it is treated just like a normal environment variable, and
portage doesn't touch it.

For most gettext packages, there is absolutely no reason that the
ebuild maintainer should have to keep track of every translation
available in a given package across version bumps. If you change this
behavior in a future EAPI, you will break this.

Re: [gentoo-dev] RFC: l10n.eclass

[Ciaran McCreesh]

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

On Fri, 20 Jul 2012 12:39:21 -0400
Mike Gilbert <floppym@gentoo.org> wrote:
> On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > On Thu, 19 Jul 2012 18:34:41 -0400
> > Mike Gilbert <floppym@gentoo.org> wrote:
> >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico@gentoo.org>
> >> wrote:
> >> > On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
> >> >> Could be that Portage re-exports a sanitized
> >> >> LINGUAS tough, but I doubt it.
> >> >
> >> > Portage does sanitize it if there are any linguas_* flags in
> >> > IUSE, otherwise it lets the variable pass through without
> >> > sanitizing it.
> >>
> >> That's good; we definitely don't want to "sanitize" it if there
> >> are no linuguas_* flags in IUSE. This would break LINUGUAS support
> >> for many autotools/gettext based packages, where the autotools
> >> code parses LINGUAS directly and the ebuild does nothing with it.
> >
> > If there aren't any linguas_* flags in IUSE, LINGUAS should be
> > empty, and will be in future EAPIs. Without that, USE dependencies
> > on USE_EXPAND variables don't work.
> 
> How do you figure that?

If you dep upon foo[linguas_en(+)] and linguas_en isn't in IUSE, what
happens?

> The current portage behavior works well enough; if linugas_* is in
> IUSE, LINGUAS is treated as a USE_EXPAND, and use-deps should work
> fine.
> 
> Otherwise, it is treated just like a normal environment variable, and
> portage doesn't touch it.

It's not a normal environment variable, and it never has been.

> For most gettext packages, there is absolutely no reason that the
> ebuild maintainer should have to keep track of every translation
> available in a given package across version bumps. If you change this
> behavior in a future EAPI, you will break this.

Don't use a USE_EXPAND variable if you don't want USE_EXPAND behaviour.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: l10n.eclass

[Mike Gilbert]

On Fri, Jul 20, 2012 at 1:09 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Fri, 20 Jul 2012 12:39:21 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
>> On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
>> <ciaran.mccreesh@googlemail.com> wrote:
>> > On Thu, 19 Jul 2012 18:34:41 -0400
>> > Mike Gilbert <floppym@gentoo.org> wrote:
>> >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico@gentoo.org>
>> >> wrote:
>> >> > On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
>> >> >> Could be that Portage re-exports a sanitized
>> >> >> LINGUAS tough, but I doubt it.
>> >> >
>> >> > Portage does sanitize it if there are any linguas_* flags in
>> >> > IUSE, otherwise it lets the variable pass through without
>> >> > sanitizing it.
>> >>
>> >> That's good; we definitely don't want to "sanitize" it if there
>> >> are no linuguas_* flags in IUSE. This would break LINUGUAS support
>> >> for many autotools/gettext based packages, where the autotools
>> >> code parses LINGUAS directly and the ebuild does nothing with it.
>> >
>> > If there aren't any linguas_* flags in IUSE, LINGUAS should be
>> > empty, and will be in future EAPIs. Without that, USE dependencies
>> > on USE_EXPAND variables don't work.
>>
>> How do you figure that?
>
> If you dep upon foo[linguas_en(+)] and linguas_en isn't in IUSE, what
> happens?
>

Firstly, if there are no linugas_ flags in IUSE, I can't see any point
in such a dependency.

Given the current behavior, I believe the dependency would always
satisfied due to the (+). That seems fine to me.

>> The current portage behavior works well enough; if linugas_* is in
>> IUSE, LINGUAS is treated as a USE_EXPAND, and use-deps should work
>> fine.
>>
>> Otherwise, it is treated just like a normal environment variable, and
>> portage doesn't touch it.
>
> It's not a normal environment variable, and it never has been.
>

It was a normal variable before someone added it to USE_EXPAND. From
cvs, it looks like that happened in 2005 or so.

>> For most gettext packages, there is absolutely no reason that the
>> ebuild maintainer should have to keep track of every translation
>> available in a given package across version bumps. If you change this
>> behavior in a future EAPI, you will break this.
>
> Don't use a USE_EXPAND variable if you don't want USE_EXPAND behaviour.
>

I beleive LINGUAS originates from the autoconf macros (po.m4) provided
by the gettext package. I believe we added it to USE_EXPAND some time
after it was implemented in gettext. This "just works" given the
current portage behavior.

Perhaps we need to provide a cleaner way for ebuilds to specify if a
given variable should be treated as a USE_EXPAND or not.

Re: [gentoo-dev] RFC: l10n.eclass

[Ciaran McCreesh]

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

On Fri, 20 Jul 2012 13:29:24 -0400
Mike Gilbert <floppym@gentoo.org> wrote:
> > If you dep upon foo[linguas_en(+)] and linguas_en isn't in IUSE,
> > what happens?
> >
> 
> Firstly, if there are no linugas_ flags in IUSE, I can't see any point
> in such a dependency.

If linguas_ is in IUSE for some versions and not others. You know, as
(+) dependencies always expect.

> > It's not a normal environment variable, and it never has been.
> 
> It was a normal variable before someone added it to USE_EXPAND. From
> cvs, it looks like that happened in 2005 or so.

...which is plenty long enough to have dealt with the consequences.

> >> For most gettext packages, there is absolutely no reason that the
> >> ebuild maintainer should have to keep track of every translation
> >> available in a given package across version bumps. If you change
> >> this behavior in a future EAPI, you will break this.
> >
> > Don't use a USE_EXPAND variable if you don't want USE_EXPAND
> > behaviour.
> 
> I beleive LINGUAS originates from the autoconf macros (po.m4) provided
> by the gettext package. I believe we added it to USE_EXPAND some time
> after it was implemented in gettext. This "just works" given the
> current portage behavior.

The problem with "just works" is that it "just works unless you look
closely or unless you try to do something slightly non-trivial". We're
not dealing with a small system here, so we need to move beyond "just
works (sort of)" to "correct". We can't provide people with the
features they're asking for without that.

> Perhaps we need to provide a cleaner way for ebuilds to specify if a
> given variable should be treated as a USE_EXPAND or not.

USE_EXPAND isn't a per ebuild setting.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: l10n.eclass

[Alexandre Rostovtsev]

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

On Fri, 2012-07-20 at 18:09 +0100, Ciaran McCreesh wrote:
> On Fri, 20 Jul 2012 12:39:21 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
> > On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
> > <ciaran.mccreesh@googlemail.com> wrote:
> > > On Thu, 19 Jul 2012 18:34:41 -0400
> > > Mike Gilbert <floppym@gentoo.org> wrote:
> > >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico@gentoo.org>
> > >> wrote:
> > >> > On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
> > >> >> Could be that Portage re-exports a sanitized
> > >> >> LINGUAS tough, but I doubt it.
> > >> >
> > >> > Portage does sanitize it if there are any linguas_* flags in
> > >> > IUSE, otherwise it lets the variable pass through without
> > >> > sanitizing it.
> > >>
> > >> That's good; we definitely don't want to "sanitize" it if there
> > >> are no linuguas_* flags in IUSE. This would break LINUGUAS support
> > >> for many autotools/gettext based packages, where the autotools
> > >> code parses LINGUAS directly and the ebuild does nothing with it.
> > >
> > > If there aren't any linguas_* flags in IUSE, LINGUAS should be
> > > empty, and will be in future EAPIs. Without that, USE dependencies
> > > on USE_EXPAND variables don't work.
> > 
> > How do you figure that?
> 
> If you dep upon foo[linguas_en(+)] and linguas_en isn't in IUSE, what
> happens?

Fatal error. If a package installs its translations implicitly via
gettext's rules depending on the value of LINGUAS at configure time,
then obviously other packages must rely on that package having installed
any particular translation.

> > The current portage behavior works well enough; if linugas_* is in
> > IUSE, LINGUAS is treated as a USE_EXPAND, and use-deps should work
> > fine.
> > 
> > Otherwise, it is treated just like a normal environment variable, and
> > portage doesn't touch it.
> 
> It's not a normal environment variable, and it never has been.

LINGUAS has been an environment variable with a special meaning for
gettext-based build systems, which are rather popular in the free
software world, since, oh, at least the year 2002 or so, when
gettext-0.11 was released. Maybe even earlier.

> > For most gettext packages, there is absolutely no reason that the
> > ebuild maintainer should have to keep track of every translation
> > available in a given package across version bumps. If you change this
> > behavior in a future EAPI, you will break this.
> 
> Don't use a USE_EXPAND variable if you don't want USE_EXPAND behaviour.

Thousands of packages rely on a particular interpretation of LINGUAS
that has been standard across all distros for a decade. If that behavior
changed in EAPI5, then EAPI5 is not suitable for adoption in Gentoo.

-Alexandre.

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

Re: [gentoo-dev] RFC: l10n.eclass

[Alexandre Rostovtsev]

Sorry, bad typo:

On Fri, 2012-07-20 at 13:43 -0400, Alexandre Rostovtsev wrote:
> then obviously other packages must rely on that package having installed
> any particular translation.

Should read "then obviously other packages must *not* rely"

-Alexandre

Re: [gentoo-dev] RFC: l10n.eclass

[Ciaran McCreesh]

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

On Fri, 20 Jul 2012 13:43:15 -0400
Alexandre Rostovtsev <tetromino@gentoo.org> wrote:
> > If you dep upon foo[linguas_en(+)] and linguas_en isn't in IUSE,
> > what happens?
> 
> Fatal error. If a package installs its translations implicitly via
> gettext's rules depending on the value of LINGUAS at configure time,
> then obviously other packages must rely on that package having
> installed any particular translation.

Uh, the entire point of the (+) is that it's *not* a fatal error if you
have a default.

> > > Otherwise, it is treated just like a normal environment variable,
> > > and portage doesn't touch it.
> > 
> > It's not a normal environment variable, and it never has been.
> 
> LINGUAS has been an environment variable with a special meaning for
> gettext-based build systems, which are rather popular in the free
> software world, since, oh, at least the year 2002 or so, when
> gettext-0.11 was released. Maybe even earlier.

And? Gentoo has decided to handle it otherwise.

> > > For most gettext packages, there is absolutely no reason that the
> > > ebuild maintainer should have to keep track of every translation
> > > available in a given package across version bumps. If you change
> > > this behavior in a future EAPI, you will break this.
> > 
> > Don't use a USE_EXPAND variable if you don't want USE_EXPAND
> > behaviour.
> 
> Thousands of packages rely on a particular interpretation of LINGUAS
> that has been standard across all distros for a decade. If that
> behavior changed in EAPI5, then EAPI5 is not suitable for adoption in
> Gentoo.

The feature was already approved by the Council for the EAPI originally
known as 3. It's necessary to make use dependency defaults work
correctly for USE_EXPAND variables (which they currently do not, due to
it being omitted from what became EAPI 4).

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: l10n.eclass

[Alexandre Rostovtsev]

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

On Fri, 2012-07-20 at 18:54 +0100, Ciaran McCreesh wrote:
> On Fri, 20 Jul 2012 13:43:15 -0400
> Alexandre Rostovtsev <tetromino@gentoo.org> wrote:
> > > If you dep upon foo[linguas_en(+)] and linguas_en isn't in IUSE,
> > > what happens?
> > 
> > Fatal error. If a package installs its translations implicitly via
> > gettext's rules depending on the value of LINGUAS at configure time,
> > then obviously other packages must rely on that package having
> > installed any particular translation.
> 
> Uh, the entire point of the (+) is that it's *not* a fatal error if you
> have a default.

That suggests that the EAPI ought to define a second category of
USE_EXPAND flags, one that has a different treatment of (+)/(-).

Something like the following:

A dependency on $foo[linguas_bar(+)] would be considered satisfied by an
ebuild X matching $foo iff:
1. X has linguas_bar in IUSE and enabled; or
2. X does not have linguas_bar in IUSE, but there exists an ebuild Y
(which may or may not equal X) matching $foo such that Y has at least
one linguas_* flag in IUSE.

-Alexandre.

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

Re: [gentoo-dev] RFC: l10n.eclass

[Ciaran McCreesh]

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

On Fri, 20 Jul 2012 14:37:19 -0400
Alexandre Rostovtsev <tetromino@gentoo.org> wrote:
> That suggests that the EAPI ought to define a second category of
> USE_EXPAND flags, one that has a different treatment of (+)/(-).
> 
> Something like the following:
> 
> A dependency on $foo[linguas_bar(+)] would be considered satisfied by
> an ebuild X matching $foo iff:
> 1. X has linguas_bar in IUSE and enabled; or
> 2. X does not have linguas_bar in IUSE, but there exists an ebuild Y
> (which may or may not equal X) matching $foo such that Y has at least
> one linguas_* flag in IUSE.

That's sensitive to old versions ebuilds being removed from the tree, so
it's utterly unworkable.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: l10n.eclass

[Alexandre Rostovtsev]

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

On Fri, 2012-07-20 at 19:41 +0100, Ciaran McCreesh wrote:
> On Fri, 20 Jul 2012 14:37:19 -0400
> Alexandre Rostovtsev <tetromino@gentoo.org> wrote:
> > That suggests that the EAPI ought to define a second category of
> > USE_EXPAND flags, one that has a different treatment of (+)/(-).
> > 
> > Something like the following:
> > 
> > A dependency on $foo[linguas_bar(+)] would be considered satisfied by
> > an ebuild X matching $foo iff:
> > 1. X has linguas_bar in IUSE and enabled; or
> > 2. X does not have linguas_bar in IUSE, but there exists an ebuild Y
> > (which may or may not equal X) matching $foo such that Y has at least
> > one linguas_* flag in IUSE.
> 
> That's sensitive to old versions ebuilds being removed from the tree, so
> it's utterly unworkable.

I do not see why you think it's unworkable. Ebuilds already have
dependencies that can be broken by removing an old version; if wombat
depends on foo[bar], and you removed the only version of foo that had
bar in IUSE, you broke wombat. Adding special LINGUAS handling would not
change the fact that before deleting an ebuild, you need to verify that
you did not render other ebuilds' dependencies unsatisfiable.

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

Re: [gentoo-dev] RFC: l10n.eclass

[Ciaran McCreesh]

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

On Fri, 20 Jul 2012 15:15:31 -0400
Alexandre Rostovtsev <tetromino@gentoo.org> wrote:
> > That's sensitive to old versions ebuilds being removed from the
> > tree, so it's utterly unworkable.
> 
> I do not see why you think it's unworkable. Ebuilds already have
> dependencies that can be broken by removing an old version; if wombat
> depends on foo[bar], and you removed the only version of foo that had
> bar in IUSE, you broke wombat. Adding special LINGUAS handling would
> not change the fact that before deleting an ebuild, you need to
> verify that you did not render other ebuilds' dependencies
> unsatisfiable.

That's not how undefaulted use dependencies work. If wombat depends
upon foo[bar], it is an error if there is *any* version of foo *ever*
that doesn't have bar in IUSE_EFFECTIVE.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: l10n.eclass

[Alexandre Rostovtsev]

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

On Fri, 2012-07-20 at 20:17 +0100, Ciaran McCreesh wrote:
> On Fri, 20 Jul 2012 15:15:31 -0400
> Alexandre Rostovtsev <tetromino@gentoo.org> wrote:
> > > That's sensitive to old versions ebuilds being removed from the
> > > tree, so it's utterly unworkable.
> > 
> > I do not see why you think it's unworkable. Ebuilds already have
> > dependencies that can be broken by removing an old version; if wombat
> > depends on foo[bar], and you removed the only version of foo that had
> > bar in IUSE, you broke wombat. Adding special LINGUAS handling would
> > not change the fact that before deleting an ebuild, you need to
> > verify that you did not render other ebuilds' dependencies
> > unsatisfiable.
> 
> That's not how undefaulted use dependencies work. If wombat depends
> upon foo[bar], it is an error if there is *any* version of foo *ever*
> that doesn't have bar in IUSE_EFFECTIVE.

Very odd; AFAICT neither portage nor repoman treats that situation as an
error. I am guessing that this is another case where paludis does things
differently?

Be that as it may, even with paludis, the foo maintainer could easily
break wombat if wombat depended on foo:bar, and the last ebuild matching
foo:bar got removed; or on foo[bar,baz], and the only remaining versions
of foo in the tree have REQUIRED_USE="^^ ( bar baz )"; or on foo[bar],
when the only remaining versions of foo in the tree have bar disabled
via profiles/base/package.use.mask.

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

Re: [gentoo-dev] RFC: l10n.eclass

[Ciaran McCreesh]

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

On Fri, 20 Jul 2012 15:48:34 -0400
Alexandre Rostovtsev <tetromino@gentoo.org> wrote:
> On Fri, 2012-07-20 at 20:17 +0100, Ciaran McCreesh wrote:
> > On Fri, 20 Jul 2012 15:15:31 -0400
> > Alexandre Rostovtsev <tetromino@gentoo.org> wrote:
> > > > That's sensitive to old versions ebuilds being removed from the
> > > > tree, so it's utterly unworkable.
> > > 
> > > I do not see why you think it's unworkable. Ebuilds already have
> > > dependencies that can be broken by removing an old version; if
> > > wombat depends on foo[bar], and you removed the only version of
> > > foo that had bar in IUSE, you broke wombat. Adding special
> > > LINGUAS handling would not change the fact that before deleting
> > > an ebuild, you need to verify that you did not render other
> > > ebuilds' dependencies unsatisfiable.
> > 
> > That's not how undefaulted use dependencies work. If wombat depends
> > upon foo[bar], it is an error if there is *any* version of foo
> > *ever* that doesn't have bar in IUSE_EFFECTIVE.
> 
> Very odd; AFAICT neither portage nor repoman treats that situation as
> an error. I am guessing that this is another case where paludis does
> things differently?

Paludis yells. Portage silently ignores the error and does something
unexpected. The spec is clear that it is an error, though.

> Be that as it may, even with paludis, the foo maintainer could easily
> break wombat if wombat depended on foo:bar, and the last ebuild
> matching foo:bar got removed; or on foo[bar,baz], and the only
> remaining versions of foo in the tree have REQUIRED_USE="^^ ( bar baz
> )"; or on foo[bar], when the only remaining versions of foo in the
> tree have bar disabled via profiles/base/package.use.mask.

Which is why it's policy that you check every dependent before making
changes to a package. You *do* follow that policy, and not just assume
that repoman passing means it's fine, right?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: l10n.eclass

[Alexandre Rostovtsev]

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

On Fri, 2012-07-20 at 21:02 +0100, Ciaran McCreesh wrote:
> Which is why it's policy that you check every dependent before making
> changes to a package. You *do* follow that policy, and not just assume
> that repoman passing means it's fine, right?

Excellent. So we are finally in agreement that one *already* needs to
check every dependent before making changes to a package - in other
words, that implementing my LINGUAS proposal would not change that part
of the required workflow for an ebuild maintainer.

It's good to see us finally agree on something :)


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

Re: [gentoo-dev] RFC: l10n.eclass

[Ciaran McCreesh]

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

On Fri, 20 Jul 2012 16:10:58 -0400
Alexandre Rostovtsev <tetromino@gentoo.org> wrote:
> On Fri, 2012-07-20 at 21:02 +0100, Ciaran McCreesh wrote:
> > Which is why it's policy that you check every dependent before
> > making changes to a package. You *do* follow that policy, and not
> > just assume that repoman passing means it's fine, right?
> 
> Excellent. So we are finally in agreement that one *already* needs to
> check every dependent before making changes to a package - in other
> words, that implementing my LINGUAS proposal would not change that
> part of the required workflow for an ebuild maintainer.

It would, though, because ebuilds exist in VDB and in overlays too.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: l10n.eclass

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 20/07/12 03:48 PM, Alexandre Rostovtsev wrote:
> On Fri, 2012-07-20 at 20:17 +0100, Ciaran McCreesh wrote:
>> On Fri, 20 Jul 2012 15:15:31 -0400 Alexandre Rostovtsev
>> <tetromino@gentoo.org> wrote:
>>>> That's sensitive to old versions ebuilds being removed from
>>>> the tree, so it's utterly unworkable.
>>> 
>>> I do not see why you think it's unworkable. Ebuilds already
>>> have dependencies that can be broken by removing an old
>>> version; if wombat depends on foo[bar], and you removed the
>>> only version of foo that had bar in IUSE, you broke wombat.
>>> Adding special LINGUAS handling would not change the fact that
>>> before deleting an ebuild, you need to verify that you did not
>>> render other ebuilds' dependencies unsatisfiable.
>> 
>> That's not how undefaulted use dependencies work. If wombat
>> depends upon foo[bar], it is an error if there is *any* version
>> of foo *ever* that doesn't have bar in IUSE_EFFECTIVE.
> 
> Very odd; AFAICT neither portage nor repoman treats that situation
> as an error. I am guessing that this is another case where paludis
> does things differently?

After discussion in #-dev I would tend to agree.  For instance, a dep
on app-cat/foo[flag(-)] resolves identically in portage to
app-cat/foo[flag]

(this means btw that the '(-)' only has meaning when using a negated
use dep, ie:  app-cat/foo[-flag(-)] does something useful, otherwise
it doesnt)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAJu3YACgkQ2ugaI38ACPA1ngD9FVbdMb+2jw/+yj/0NIQ28mdz
YYmXytaoefN0NaBM4bAA/jFmkgkcvrqbtQARbHUaqfFBgJHLVlM1cjk35KE+gKMS
=KZJc
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: l10n.eclass

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 20/07/12 01:54 PM, Ciaran McCreesh wrote:
> On Fri, 20 Jul 2012 13:43:15 -0400 Alexandre Rostovtsev
> <tetromino@gentoo.org> wrote:
>>> If you dep upon foo[linguas_en(+)] and linguas_en isn't in
>>> IUSE, what happens?
>> 
>> Fatal error. If a package installs its translations implicitly
>> via gettext's rules depending on the value of LINGUAS at
>> configure time, then obviously other packages must rely on that
>> package having installed any particular translation.
> 
> Uh, the entire point of the (+) is that it's *not* a fatal error if
> you have a default.
> 

If this doesn't work (assuming foo provides whatever this package
needs it to have for linguas_en), then the dep is wrong in the first
place and either (+) shouldn't be set or the use-dep on foo shouldn't
exist to begin with.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAJq/4ACgkQ2ugaI38ACPDIrgEAlPMn/3pSM/GK3BbCozQgGpxc
9aSnmtIXlOsr7HZ7QcUA/1dbtqqt6B/ClgriFHvHcVpZEiz5QiQh6RJ2t4Mr5jgk
=ai7O
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: l10n.eclass

[Ciaran McCreesh]

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

On Fri, 20 Jul 2012 15:05:35 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> On 20/07/12 01:54 PM, Ciaran McCreesh wrote:
> > On Fri, 20 Jul 2012 13:43:15 -0400 Alexandre Rostovtsev
> > <tetromino@gentoo.org> wrote:
> >>> If you dep upon foo[linguas_en(+)] and linguas_en isn't in
> >>> IUSE, what happens?
> >> 
> >> Fatal error. If a package installs its translations implicitly
> >> via gettext's rules depending on the value of LINGUAS at
> >> configure time, then obviously other packages must rely on that
> >> package having installed any particular translation.
> > 
> > Uh, the entire point of the (+) is that it's *not* a fatal error if
> > you have a default.
> 
> If this doesn't work (assuming foo provides whatever this package
> needs it to have for linguas_en), then the dep is wrong in the first
> place and either (+) shouldn't be set or the use-dep on foo shouldn't
> exist to begin with.

...but (+) exists precisely because developers wanted a way of not
having fatal errors when using use dependencies. Non-defaulted use
dependencies are supposed to give errors if there's no match in
IUSE_EFFECTIVE, but unfortunately Portage chose not to make it as
strict as the Council-approved wording required.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlAJrfgACgkQ96zL6DUtXhGjGACfdsaHwmKKq13EtlS9Jna0ueSj
vc4An3xifK/Y2V2SwPc2k19kYmLlHZUk
=eIrd
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: l10n.eclass

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 20/07/12 03:13 PM, Ciaran McCreesh wrote:
> On Fri, 20 Jul 2012 15:05:35 -0400 Ian Stakenvicius
> <axs@gentoo.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 20/07/12 01:54
>> PM, Ciaran McCreesh wrote:
>>> On Fri, 20 Jul 2012 13:43:15 -0400 Alexandre Rostovtsev 
>>> <tetromino@gentoo.org> wrote:
>>>>> If you dep upon foo[linguas_en(+)] and linguas_en isn't in 
>>>>> IUSE, what happens?
>>>> 
>>>> Fatal error. If a package installs its translations
>>>> implicitly via gettext's rules depending on the value of
>>>> LINGUAS at configure time, then obviously other packages must
>>>> rely on that package having installed any particular
>>>> translation.
>>> 
>>> Uh, the entire point of the (+) is that it's *not* a fatal
>>> error if you have a default.
> 
>> If this doesn't work (assuming foo provides whatever this
>> package needs it to have for linguas_en), then the dep is wrong
>> in the first place and either (+) shouldn't be set or the use-dep
>> on foo shouldn't exist to begin with.
> 
> ...but (+) exists precisely because developers wanted a way of not 
> having fatal errors when using use dependencies. Non-defaulted use 
> dependencies are supposed to give errors if there's no match in 
> IUSE_EFFECTIVE, but unfortunately Portage chose not to make it as 
> strict as the Council-approved wording required.
> 

non-fatal doesn't work in this case, because in the situation you
described, the dep 'foo' -must- have linguas_en existing and enabled
to work.

IF foo doesn't -need- to have linguas_en existing and enabled to work,
ie, if linguas_en doesn't exist but foo installed the relevant bits
anyways, then foo[linguas_en(+)] is valid and works fine.

Otherwise, the dep specified is wrong and it SHOULD be a fatal error.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAJuqAACgkQ2ugaI38ACPApyQD/dtMj1l0KeJByIXXIhS+Y3Xst
pj2/eoQ7q1ze2vhfPgQBALA+UatwFysIXRuFCiXrVt4vK0OlMNa58GIRpsonzGMz
=cPuz
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: l10n.eclass

[Michał Górny]

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

On Fri, 20 Jul 2012 12:39:21 -0400
Mike Gilbert <floppym@gentoo.org> wrote:

> For most gettext packages, there is absolutely no reason that the
> ebuild maintainer should have to keep track of every translation
> available in a given package across version bumps. If you change this
> behavior in a future EAPI, you will break this.
 
Either he has to do that, or he should just remove the pointless,
useless and unmaintained LINGUAS from his ebuild and just install
everything.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] RFC: l10n.eclass

[Alexandre Rostovtsev]

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

On Fri, 2012-07-20 at 19:44 +0200, Michał Górny wrote:
> On Fri, 20 Jul 2012 12:39:21 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
> 
> > For most gettext packages, there is absolutely no reason that the
> > ebuild maintainer should have to keep track of every translation
> > available in a given package across version bumps. If you change this
> > behavior in a future EAPI, you will break this.
>  
> Either he has to do that, or he should just remove the pointless,
> useless and unmaintained LINGUAS from his ebuild and just install
> everything.

Currently, "install everything" is treated as a bug - see
https://bugs.gentoo.org/show_bug.cgi?id=405485

If you ignore LINGUAS and install everything, you break the
long-established convention for what LINGUAS does, make users angry,
waste disk space, and increase build time for packages with lots of
translations - all for no good reason other than forcing uniform
USE_EXPAND conventions in a place where they aren't wanted.

-Alexandre.

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

Re: [gentoo-dev] RFC: l10n.eclass

[Mike Gilbert]

On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Thu, 19 Jul 2012 18:34:41 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
>> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico@gentoo.org>
>> wrote:
>> > On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
>> >> Could be that Portage re-exports a sanitized
>> >> LINGUAS tough, but I doubt it.
>> >
>> > Portage does sanitize it if there are any linguas_* flags in IUSE,
>> > otherwise it lets the variable pass through without sanitizing it.
>>
>> That's good; we definitely don't want to "sanitize" it if there are no
>> linuguas_* flags in IUSE. This would break LINUGUAS support for many
>> autotools/gettext based packages, where the autotools code parses
>> LINGUAS directly and the ebuild does nothing with it.
>
> If there aren't any linguas_* flags in IUSE, LINGUAS should be empty,
> and will be in future EAPIs. Without that, USE dependencies on
> USE_EXPAND variables don't work.
>

Do you mean that LINGUAS will be empty, or unset (undefined) in an
ebuild context? The difference is significant here.

Re: [gentoo-dev] RFC: l10n.eclass

[Ciaran McCreesh]

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

On Fri, 20 Jul 2012 13:55:46 -0400
Mike Gilbert <floppym@gentoo.org> wrote:
> On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > On Thu, 19 Jul 2012 18:34:41 -0400
> > Mike Gilbert <floppym@gentoo.org> wrote:
> >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico@gentoo.org>
> >> wrote:
> >> > On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
> >> >> Could be that Portage re-exports a sanitized
> >> >> LINGUAS tough, but I doubt it.
> >> >
> >> > Portage does sanitize it if there are any linguas_* flags in
> >> > IUSE, otherwise it lets the variable pass through without
> >> > sanitizing it.
> >>
> >> That's good; we definitely don't want to "sanitize" it if there
> >> are no linuguas_* flags in IUSE. This would break LINUGUAS support
> >> for many autotools/gettext based packages, where the autotools
> >> code parses LINGUAS directly and the ebuild does nothing with it.
> >
> > If there aren't any linguas_* flags in IUSE, LINGUAS should be
> > empty, and will be in future EAPIs. Without that, USE dependencies
> > on USE_EXPAND variables don't work.
> 
> Do you mean that LINGUAS will be empty, or unset (undefined) in an
> ebuild context? The difference is significant here.

For EAPIs before 5, LINGUAS contains *at least* the things in IUSE
intersected with the ones the user has enabled, with the linguas_
stripped. It's not just "the environment variable in make.conf", since a
user might put linguas_en in package.use.

For EAPIs 5 and onwards, LINGUAS contains only those things, and
definitely won't contain anything else.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: l10n.eclass

[Mike Gilbert]

On Fri, Jul 20, 2012 at 2:03 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Fri, 20 Jul 2012 13:55:46 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
>> On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
>> <ciaran.mccreesh@googlemail.com> wrote:
>> > On Thu, 19 Jul 2012 18:34:41 -0400
>> > Mike Gilbert <floppym@gentoo.org> wrote:
>> >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico@gentoo.org>
>> >> wrote:
>> >> > On 07/19/2012 06:14 AM, Ralph Sennhauser wrote:
>> >> >> Could be that Portage re-exports a sanitized
>> >> >> LINGUAS tough, but I doubt it.
>> >> >
>> >> > Portage does sanitize it if there are any linguas_* flags in
>> >> > IUSE, otherwise it lets the variable pass through without
>> >> > sanitizing it.
>> >>
>> >> That's good; we definitely don't want to "sanitize" it if there
>> >> are no linuguas_* flags in IUSE. This would break LINUGUAS support
>> >> for many autotools/gettext based packages, where the autotools
>> >> code parses LINGUAS directly and the ebuild does nothing with it.
>> >
>> > If there aren't any linguas_* flags in IUSE, LINGUAS should be
>> > empty, and will be in future EAPIs. Without that, USE dependencies
>> > on USE_EXPAND variables don't work.
>>
>> Do you mean that LINGUAS will be empty, or unset (undefined) in an
>> ebuild context? The difference is significant here.
>
> For EAPIs before 5, LINGUAS contains *at least* the things in IUSE
> intersected with the ones the user has enabled, with the linguas_
> stripped. It's not just "the environment variable in make.conf", since a
> user might put linguas_en in package.use.
>
> For EAPIs 5 and onwards, LINGUAS contains only those things, and
> definitely won't contain anything else.

Let me rephrase my question: If the user has not enabled any of the
linguas flags via make.conf or package.use, will the LINGUAS variable
be empty or unset in the ebuild environment?

Re: [gentoo-dev] RFC: l10n.eclass

[Ciaran McCreesh]

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

On Fri, 20 Jul 2012 14:09:28 -0400
Mike Gilbert <floppym@gentoo.org> wrote:
> Let me rephrase my question: If the user has not enabled any of the
> linguas flags via make.conf or package.use, will the LINGUAS variable
> be empty or unset in the ebuild environment?

Empty.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] RFC: l10n.eclass

[Mike Gilbert]

On Thu, Jul 19, 2012 at 2:45 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> Today I would like to present to you my proposal for a new eclass with
> helper functions for treating localizations: l10n.eclass (see the
> attached file or [1]). Its functionality can be used in other eclasses
> (such as qt4-r2 and cmake-utils) as well as directly in ebuilds.
>

In a previous thread, I proposed that the linguas_* use flags should
default to enabled (IUSE="+linguas_en_US ...").

This would cause LINGUAS use-expand behavior to more closely mimic the
behavior of the gettext autoconf macros (/usr/share/aclocal/po.m4).

If LINGUAS is unset, all translations are installed.
If LINGUAS is set a subset of translations are install.
If LINGUAS is set to the empty string, no translations are installed.