-----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+UatwFysIXRuFCiXrVt4vK0OlMNa58G IRpsonzGMz
=cPuz
-----END PGP SIGNATURE-----

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

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

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

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

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.