Re: [gentoo-dev] RFC: l10n.eclass
On Thu, 19 Jul 2012 23:37:32 +0800
Ben de Groot 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.
signature.asc
Description: PGP signature
[gentoo-dev] enewuser: home beloning $user:root inset of $user:$group
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
is it intentional behavior, that home directories created by enewuser
belong to $user:root (or pwd group) instead of $user:$group ?
I recently set net-misc/minidlna to run as non-root and ended up with
minidlna:minidlna, see [1] for implementation details (and my
workaround) and [2,3] for the discussion leading to the situation.
p.s. I aware that chown/chmod and missing ${EPREFIX} makes this a bad
hack and fails on Prefix.
Michael
[2] https://bugs.gentoo.org/394373
[3] https://bugs.gentoo.org/426726
- --
Gentoo Dev
http://xmw.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iF4EAREIAAYFAlAJF5YACgkQknrdDGLu8JAoQQD/U2vrcw/bOuGtmcKelM7gbfh9
aV+Nqk89M7re+gYLhY8A/RLSaNztCvQ+ti/ZYeETDEcui7wmT1kEuilxjwz1RrPV
=9ogI
-END PGP SIGNATURE-
Re: [gentoo-dev] enewuser: home beloning $user:root inset of $user:$group
On Fri, Jul 20, 2012 at 11:32 AM, Michael Weber wrote: > is it intentional behavior, that home directories created by enewuser > belong to $user:root (or pwd group) instead of $user:$group ? This seems like the result of a hasty bugfix to me: https://bugs.gentoo.org/23627 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/eutils.eclass?r1=1.36&r2=1.37 Wrong group ownership shouldn't matter much, since ebuilds should probably explicitly set home directory ownership / permissions with fowners / fperms anyway (in src_install()). However, that doesn't work due to: https://bugs.gentoo.org/396153 Having a switch for enewuser to skip creating home directory would solve the issue for majority of usecases, but a request I opened was resolved as a duplicate of the bug above (which I don't expect to be resolved anytime soon): https://bugs.gentoo.org/395961 -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] enewuser: home beloning $user:root inset of $user:$group
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/07/12 06:18 AM, Maxim Kammerer wrote: > On Fri, Jul 20, 2012 at 11:32 AM, Michael Weber > wrote: >> is it intentional behavior, that home directories created by >> enewuser belong to $user:root (or pwd group) instead of >> $user:$group ? > > This seems like the result of a hasty bugfix to me: > https://bugs.gentoo.org/23627 > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/eutils.eclass?r1=1.36&r2=1.37 > > Wrong group ownership shouldn't matter much, since ebuilds should > probably explicitly set home directory ownership / permissions > with fowners / fperms anyway (in src_install()). However, that > doesn't work due to: https://bugs.gentoo.org/396153 > > Having a switch for enewuser to skip creating home directory would > solve the issue for majority of usecases, but a request I opened > was resolved as a duplicate of the bug above (which I don't expect > to be resolved anytime soon): https://bugs.gentoo.org/395961 > enewuser won't create a home directory if you don't specify one (ie it's set to /dev/null or it's unset). Also, you can use 'esethome' to set the home directory to an existing directory. With both of these options I don't think that a --do-not-create-homedir option is necessary. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlAJd+YACgkQ2ugaI38ACPDmLgD8C/CifrMost6b5cYVZn3R+FnU K3Qf6Tp85S/gSPT7fC0A/ikEDaKGQxqainhzWRfl0fyyb6MSRZphzcz+uwb+Y/1t =yFDr -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: l10n.eclass
On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh wrote: > On Thu, 19 Jul 2012 18:34:41 -0400 > Mike Gilbert wrote: >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico >> 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.
Re: [gentoo-dev] enewuser: home beloning $user:root inset of $user:$group
On Fri, Jul 20, 2012 at 6:23 PM, Ian Stakenvicius wrote: > enewuser won't create a home directory if you don't specify one (ie > it's set to /dev/null or it's unset). Also, you can use 'esethome' to > set the home directory to an existing directory. With both of these > options I don't think that a --do-not-create-homedir option is necessary. Well, with this approach there will now be three separate code blocks, just to create user's home directory: enewuser in pkg_preinst(), fperms / fowners in src_install(), and esethome in pkg_postinst(). Changing permissions as suggested by Kevin Pyle [1] looks more attractive then, since everything is in one code block. Moreover, if you want to keep the same semantics with esethome (only set the home directory when the user is created), you will need to keep a variable across ebuild phases. Also, it looks like pkg_postinst() is on the way out [2]. All-in-all, I think that a --do-not-create-homedir (or a shorter equivalent) is a good idea. [1] https://bugs.gentoo.org/show_bug.cgi?id=395961#c1 [2] http://archives.gentoo.org/gentoo-dev/msg_ed43ed0df212ea26ef953fb061e9e860.xml -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] RFC: l10n.eclass
On Fri, 20 Jul 2012 12:39:21 -0400 Mike Gilbert wrote: > On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh > wrote: > > On Thu, 19 Jul 2012 18:34:41 -0400 > > Mike Gilbert wrote: > >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico > >> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: l10n.eclass
On Fri, Jul 20, 2012 at 1:09 PM, Ciaran McCreesh wrote: > On Fri, 20 Jul 2012 12:39:21 -0400 > Mike Gilbert wrote: >> On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh >> wrote: >> > On Thu, 19 Jul 2012 18:34:41 -0400 >> > Mike Gilbert wrote: >> >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico >> >> 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.
Re: [gentoo-dev] RFC: l10n.eclass
On Fri, 20 Jul 2012 13:29:24 -0400 Mike Gilbert 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 signature.asc Description: PGP signature
Re: [gentoo-dev] 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 wrote: > > On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh > > wrote: > > > On Thu, 19 Jul 2012 18:34:41 -0400 > > > Mike Gilbert wrote: > > >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico > > >> 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. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: l10n.eclass
On Fri, 20 Jul 2012 12:39:21 -0400 Mike Gilbert 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 signature.asc Description: PGP signature
Re: [gentoo-dev] 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
Re: [gentoo-dev] RFC: l10n.eclass
On Fri, 20 Jul 2012 13:43:15 -0400 Alexandre Rostovtsev 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 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: l10n.eclass
On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh wrote: > On Thu, 19 Jul 2012 18:34:41 -0400 > Mike Gilbert wrote: >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico >> 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.
Re: [gentoo-dev] 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 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. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: l10n.eclass
On Fri, 20 Jul 2012 13:55:46 -0400 Mike Gilbert wrote: > On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh > wrote: > > On Thu, 19 Jul 2012 18:34:41 -0400 > > Mike Gilbert wrote: > >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico > >> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: l10n.eclass
On Fri, Jul 20, 2012 at 2:03 PM, Ciaran McCreesh wrote: > On Fri, 20 Jul 2012 13:55:46 -0400 > Mike Gilbert wrote: >> On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh >> wrote: >> > On Thu, 19 Jul 2012 18:34:41 -0400 >> > Mike Gilbert wrote: >> >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico >> >> 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?
Re: [gentoo-dev] RFC: l10n.eclass
On Fri, 20 Jul 2012 14:09:28 -0400 Mike Gilbert 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 signature.asc Description: PGP signature
Re: [gentoo-dev] 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 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. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: l10n.eclass
On Fri, 20 Jul 2012 14:37:19 -0400 Alexandre Rostovtsev 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 signature.asc Description: PGP signature
Re: [gentoo-dev] 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 > 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-
Re: [gentoo-dev] RFC: l10n.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 20 Jul 2012 15:05:35 -0400 Ian Stakenvicius 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 > > 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) iEYEARECAAYFAlAJrfgACgkQ96zL6DUtXhGjGACfdsaHwmKKq13EtlS9Jna0ueSj vc4An3xifK/Y2V2SwPc2k19kYmLlHZUk =eIrd -END PGP SIGNATURE-
Re: [gentoo-dev] 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 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. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: l10n.eclass
On Fri, 20 Jul 2012 15:15:31 -0400 Alexandre Rostovtsev 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 signature.asc Description: PGP signature
Re: [gentoo-dev] 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 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. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: l10n.eclass
On Fri, 20 Jul 2012 15:48:34 -0400 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 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 signature.asc Description: PGP signature
Re: [gentoo-dev] 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 > 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 >>> 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+UatwFysIXRuFCiXrVt4vK0OlMNa58GIRpsonzGMz =cPuz -END PGP SIGNATURE-
Re: [gentoo-dev] 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 :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] 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 >> 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-
Re: [gentoo-dev] RFC: l10n.eclass
On Fri, 20 Jul 2012 16:10:58 -0400 Alexandre Rostovtsev 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 signature.asc Description: PGP signature
