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, 08:08 PM
Ian Stakenvicius
 
Default RFC: l10n.eclass

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

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

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

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
 
Old 07-23-2012, 12:29 PM
Ben de Groot
 
Default RFC: l10n.eclass

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
 
Old 07-23-2012, 03:22 PM
Ralph Sennhauser
 
Default RFC: l10n.eclass

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.
 

Thread Tools




All times are GMT. The time now is 01:16 PM.

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