FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 07-20-2012, 05:09 PM
Ciaran McCreesh
 
Default RFC: l10n.eclass

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
 
Old 07-20-2012, 05:29 PM
Mike Gilbert
 
Default RFC: l10n.eclass

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.
 
Old 07-20-2012, 05:35 PM
Ciaran McCreesh
 
Default RFC: l10n.eclass

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
 
Old 07-20-2012, 05:43 PM
Alexandre Rostovtsev
 
Default RFC: l10n.eclass

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.
 
Old 07-20-2012, 05:44 PM
Michał Górny
 
Default RFC: l10n.eclass

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
 
Old 07-20-2012, 05:46 PM
Alexandre Rostovtsev
 
Default RFC: l10n.eclass

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
 
Old 07-20-2012, 05:54 PM
Ciaran McCreesh
 
Default RFC: l10n.eclass

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
 
Old 07-20-2012, 05:55 PM
Mike Gilbert
 
Default RFC: l10n.eclass

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.
 
Old 07-20-2012, 06:03 PM
Ciaran McCreesh
 
Default RFC: l10n.eclass

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
 
Old 07-20-2012, 06:03 PM
Alexandre Rostovtsev
 
Default RFC: l10n.eclass

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.
 

Thread Tools




All times are GMT. The time now is 01:35 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org