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, 06:09 PM
Mike Gilbert
 
Default RFC: l10n.eclass

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

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

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

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

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

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

iEYEARECAAYFAlAJrfgACgkQ96zL6DUtXhGjGACfdsaHwmKKq1 3EtlS9Jna0ueSj
vc4An3xifK/Y2V2SwPc2k19kYmLlHZUk
=eIrd
-----END PGP SIGNATURE-----
 
Old 07-20-2012, 07:15 PM
Alexandre Rostovtsev
 
Default RFC: l10n.eclass

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

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

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

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
 

Thread Tools




All times are GMT. The time now is 12:40 AM.

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