Mailing List Archive: Gentoo: Dev

RFC: l10n.eclass

1 2

View All

Index | Next | Previous | View Threaded

yngwin at gentoo

Jul 18, 2012, 11:45 PM

Post #1 of 36 (534 views)
Permalink

RFC: l10n.eclass

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

Attachments:

l10n.eclass (3.83 KB)

sera at gentoo

Jul 19, 2012, 6:14 AM

Post #2 of 36 (518 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Thu, 19 Jul 2012 14:45:39 +0800
Ben de Groot <yngwin [at] gentoo> 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.

Attachments:

signature.asc (0.48 KB)

yngwin at gentoo

Jul 19, 2012, 8:37 AM

Post #3 of 36 (517 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On 19 July 2012 21:14, Ralph Sennhauser <sera [at] gentoo> 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

Attachments:

l10n.eclass (3.96 KB)

ciaran.mccreesh at googlemail

Jul 19, 2012, 9:15 AM

Post #4 of 36 (520 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Thu, 19 Jul 2012 15:14:22 +0200
Ralph Sennhauser <sera [at] gentoo> 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

Attachments:

signature.asc (0.19 KB)

zmedico at gentoo

Jul 19, 2012, 2:13 PM

Post #5 of 36 (517 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

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

floppym at gentoo

Jul 19, 2012, 3:34 PM

Post #6 of 36 (518 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico [at] gentoo> 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.

floppym at gentoo

Jul 19, 2012, 3:44 PM

Post #7 of 36 (522 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Thu, Jul 19, 2012 at 2:45 AM, Ben de Groot <yngwin [at] gentoo> 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.

ciaran.mccreesh at googlemail

Jul 19, 2012, 11:54 PM

Post #8 of 36 (515 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Thu, 19 Jul 2012 18:34:41 -0400
Mike Gilbert <floppym [at] gentoo> wrote:
> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico [at] gentoo>
> 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

Attachments:

signature.asc (0.19 KB)

sera at gentoo

Jul 20, 2012, 12:33 AM

Post #9 of 36 (517 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Thu, 19 Jul 2012 23:37:32 +0800
Ben de Groot <yngwin [at] gentoo> 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.

Attachments:

signature.asc (0.48 KB)

floppym at gentoo

Jul 20, 2012, 9:39 AM

Post #10 of 36 (518 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
<ciaran.mccreesh [at] googlemail> wrote:
> On Thu, 19 Jul 2012 18:34:41 -0400
> Mike Gilbert <floppym [at] gentoo> wrote:
>> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico [at] gentoo>
>> 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.

ciaran.mccreesh at googlemail

Jul 20, 2012, 10:09 AM

Post #11 of 36 (511 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Fri, 20 Jul 2012 12:39:21 -0400
Mike Gilbert <floppym [at] gentoo> wrote:
> On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
> <ciaran.mccreesh [at] googlemail> wrote:
> > On Thu, 19 Jul 2012 18:34:41 -0400
> > Mike Gilbert <floppym [at] gentoo> wrote:
> >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico [at] gentoo>
> >> 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

Attachments:

signature.asc (0.19 KB)

floppym at gentoo

Jul 20, 2012, 10:29 AM

Post #12 of 36 (517 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Fri, Jul 20, 2012 at 1:09 PM, Ciaran McCreesh
<ciaran.mccreesh [at] googlemail> wrote:
> On Fri, 20 Jul 2012 12:39:21 -0400
> Mike Gilbert <floppym [at] gentoo> wrote:
>> On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
>> <ciaran.mccreesh [at] googlemail> wrote:
>> > On Thu, 19 Jul 2012 18:34:41 -0400
>> > Mike Gilbert <floppym [at] gentoo> wrote:
>> >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico [at] gentoo>
>> >> 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.

ciaran.mccreesh at googlemail

Jul 20, 2012, 10:35 AM

Post #13 of 36 (513 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Fri, 20 Jul 2012 13:29:24 -0400
Mike Gilbert <floppym [at] gentoo> 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

Attachments:

signature.asc (0.19 KB)

tetromino at gentoo

Jul 20, 2012, 10:43 AM

Post #14 of 36 (519 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Fri, 2012-07-20 at 18:09 +0100, Ciaran McCreesh wrote:
> On Fri, 20 Jul 2012 12:39:21 -0400
> Mike Gilbert <floppym [at] gentoo> wrote:
> > On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
> > <ciaran.mccreesh [at] googlemail> wrote:
> > > On Thu, 19 Jul 2012 18:34:41 -0400
> > > Mike Gilbert <floppym [at] gentoo> wrote:
> > >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico [at] gentoo>
> > >> 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.

Attachments:

signature.asc (0.48 KB)

mgorny at gentoo

Jul 20, 2012, 10:44 AM

Post #15 of 36 (518 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Fri, 20 Jul 2012 12:39:21 -0400
Mike Gilbert <floppym [at] gentoo> 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

Attachments:

signature.asc (0.31 KB)

tetromino at gentoo

Jul 20, 2012, 10:46 AM

Post #16 of 36 (518 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

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

ciaran.mccreesh at googlemail

Jul 20, 2012, 10:54 AM

Post #17 of 36 (517 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Fri, 20 Jul 2012 13:43:15 -0400
Alexandre Rostovtsev <tetromino [at] gentoo> 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

Attachments:

signature.asc (0.19 KB)

floppym at gentoo

Jul 20, 2012, 10:55 AM

Post #18 of 36 (512 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
<ciaran.mccreesh [at] googlemail> wrote:
> On Thu, 19 Jul 2012 18:34:41 -0400
> Mike Gilbert <floppym [at] gentoo> wrote:
>> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico [at] gentoo>
>> 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.

ciaran.mccreesh at googlemail

Jul 20, 2012, 11:03 AM

Post #19 of 36 (514 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Fri, 20 Jul 2012 13:55:46 -0400
Mike Gilbert <floppym [at] gentoo> wrote:
> On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
> <ciaran.mccreesh [at] googlemail> wrote:
> > On Thu, 19 Jul 2012 18:34:41 -0400
> > Mike Gilbert <floppym [at] gentoo> wrote:
> >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico [at] gentoo>
> >> 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

Attachments:

signature.asc (0.19 KB)

tetromino at gentoo

Jul 20, 2012, 11:03 AM

Post #20 of 36 (517 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

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 [at] gentoo> 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.

Attachments:

signature.asc (0.48 KB)

floppym at gentoo

Jul 20, 2012, 11:09 AM

Post #21 of 36 (515 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Fri, Jul 20, 2012 at 2:03 PM, Ciaran McCreesh
<ciaran.mccreesh [at] googlemail> wrote:
> On Fri, 20 Jul 2012 13:55:46 -0400
> Mike Gilbert <floppym [at] gentoo> wrote:
>> On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh
>> <ciaran.mccreesh [at] googlemail> wrote:
>> > On Thu, 19 Jul 2012 18:34:41 -0400
>> > Mike Gilbert <floppym [at] gentoo> wrote:
>> >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico <zmedico [at] gentoo>
>> >> 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?

ciaran.mccreesh at googlemail

Jul 20, 2012, 11:15 AM

Post #22 of 36 (516 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Fri, 20 Jul 2012 14:09:28 -0400
Mike Gilbert <floppym [at] gentoo> 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

Attachments:

signature.asc (0.19 KB)

tetromino at gentoo

Jul 20, 2012, 11:37 AM

Post #23 of 36 (515 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Fri, 2012-07-20 at 18:54 +0100, Ciaran McCreesh wrote:
> On Fri, 20 Jul 2012 13:43:15 -0400
> Alexandre Rostovtsev <tetromino [at] gentoo> 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.

Attachments:

signature.asc (0.48 KB)

ciaran.mccreesh at googlemail

Jul 20, 2012, 11:41 AM

Post #24 of 36 (512 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

On Fri, 20 Jul 2012 14:37:19 -0400
Alexandre Rostovtsev <tetromino [at] gentoo> 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

Attachments:

signature.asc (0.19 KB)

axs at gentoo

Jul 20, 2012, 12:05 PM

Post #25 of 36 (516 views)
Permalink

Re: RFC: l10n.eclass [In reply to]

-----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 [at] gentoo> 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-----

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads