Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-crypt/gpa: gpa-0.9.3.ebuild ChangeLog gpa-0.9.1_pre20100416-r1.ebuild
On 27/08/12 16:46, Diego Elio Pettenò wrote: On 27/08/2012 00:18, Samuli Suominen wrote: why leave the ebuild read $myconf from global scope? $EXTRA_ECONF works for this Because extremely simply I forgot to delete the line. yep, as I guessed, thanks for clearing it (and just ignore rest of the thread which is pointless ;-)
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-crypt/gpa: gpa-0.9.3.ebuild ChangeLog gpa-0.9.1_pre20100416-r1.ebuild
Rich Freeman posted on Mon, 27 Aug 2012 22:25:53 -0400 as excerpted: > On Mon, Aug 27, 2012 at 10:05 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> [snip] > Honestly, while I might agree with that sentiment on some of these > threads, my only complaint with Ciaran's original response was that he > could have been a bit more direct with his concern. Rather than stating > that EXTRA_* does not exist as far as ebuilds go, he could have just > stated that PMS does not allow these variables to be used by an ebuild. >From here, that looks like a distinction without a difference... > Sure, he didn't get into the why, but I'm not sure I'd expect that. I'd > probably state it, but I'm probably the second-most-verbose person on > this list. :) =:^) (Current off-list context: There's a discussion currently going on, mdraid and lvm2, on scarabeus' "blag", with r0 and I both being rather heavy participants. =:^) > If somebody filed a bug against my package and pointed out that > something was illegal per PMS, probably the first thing I'd do is read > it to fully understand the situation, and then if I had a concern I'd > probably ask via irc/private email/etc. That is as much to avoid making > a fool out of myself in public, but also because when somebody who is > obviously knowledgeable points out something they consider a flaw, it > isn't a bad idea to give their concern full consideration. Wise words, this and the rest. Thanks. FWIW, I believe I've said what I had to say and don't expect to be commenting much further on this, tho of course I reserve the right to change my mind if something drastically provoking comes up. (For I know if I wasn't explicit with that, something /would/ come up. It just works that way...) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
2012-08-28 00:19:28 Michał Górny napisał(a):
> --- /dev/null
> +++ b/gx86/eclass/boost-utils.eclass
> @@ -0,0 +1,43 @@
> +# Copyright 1999-2012 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Header: $
> +
> +if [[ ! ${_BOOST_ECLASS} ]]; then
> +
> +# @ECLASS: boost-utils.eclass
> +# @MAINTAINER:
> +# mgo...@gentoo.org
It is better to copy list of maintainers from
gentoo-x86/dev-libs/boost/metadata.xml.
> +# @BLURB: helper functions for packages using Boost C++ library
> +# @DESCRIPTION:
> +# Helper functions to be used when building packages using the Boost C++
> +# library collection.
> +
> +case ${EAPI:-0} in
> + 0|1|2|3|4) ;;
> + *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
> +esac
Please accept all EAPIs.
> +inherit versionator
> +
> +# @FUNCTION: boost-utils_get_best_slot
> +# @DESCRIPTION:
> +# Get newest SLOT (major version) of Boost.
> +boost-utils_get_best_slot() {
> + local pkg=dev-libs/boost
> + local atom=$(best_version ${pkg})
> + get_version_component_range 1-2 ${atom#${pkg}}
> +}
> +
> +# @FUNCTION: boost-utils_get_includedir
> +# @DESCRIPTION:
> +# Get correct includedir for best Boost version. Outputs the sole path
> +# (without -I).
> +boost-utils_get_includedir() {
> + local slot=$(boost-utils_get_best_slot)
> + has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
> +
> + echo -n "${EPREFIX}/usr/include/boost-${slot/./_}"
> +}
There needs to be a way to specify maximal accepted slot of Boost. Examples of
some possibilities:
* BOOST_MAX_SLOT="1.49" global variable
* '--max 1.49' arguments for boost-utils_get_* functions
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-crypt/gpa: gpa-0.9.3.ebuild ChangeLog gpa-0.9.1_pre20100416-r1.ebuild
On Mon, Aug 27, 2012 at 10:05 PM, Duncan <1i5t5.dun...@cox.net> wrote: > That's all I'm saying. It's being made a whole lot less pleasant that it > might be... for what reason? Just to satisfy someone's ego that they're > right and can /force/ compliance? Yuck! Honestly, while I might agree with that sentiment on some of these threads, my only complaint with Ciaran's original response was that he could have been a bit more direct with his concern. Rather than stating that EXTRA_* does not exist as far as ebuilds go, he could have just stated that PMS does not allow these variables to be used by an ebuild. However, the reply to that email makes it clear that even though it was unstated Ciaran's meaning was understood. Sure, he didn't get into the why, but I'm not sure I'd expect that. I'd probably state it, but I'm probably the second-most-verbose person on this list. :) If somebody filed a bug against my package and pointed out that something was illegal per PMS, probably the first thing I'd do is read it to fully understand the situation, and then if I had a concern I'd probably ask via irc/private email/etc. That is as much to avoid making a fool out of myself in public, but also because when somebody who is obviously knowledgeable points out something they consider a flaw, it isn't a bad idea to give their concern full consideration. Sure, if PMS is wrong it ought to be fixed, but the whole point of having specifications is that you don't toss them the moment you don't like what they say. Then again, I work on regulated software in my real job, and even if the spec is wrong changing it still involves a process - you don't just ignore it (any behavior in violation of the spec is an automatic bug - even if the bug is to fix the spec - and unless pretty trivial is justification to prevent release (often this is done anyway since it is usually less work to just fix the problem than justify to the world not doing it)). In any case, it is best to not take these sorts of things personally all around. Most of us are here because our perverse tastes consider this stuff fun! :) Might as well keep it that way... Rich
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-crypt/gpa: gpa-0.9.3.ebuild ChangeLog gpa-0.9.1_pre20100416-r1.ebuild
Ciaran McCreesh posted on Mon, 27 Aug 2012 22:33:42 +0100 as excerpted: > No, you're utterly missing the point here. The spec is there to be > followed, not battled and ignored unless a justification is provided at > every step. When it comes to writing compliant ebuilds, PMS *is* the > justification. One does not simply ignore the law because one does not > like it or understand why it is the way it is. Agreed. But it can be made a pleasant experience... or not. Why make it an experience that people have to be dragged kicking and screaming into, when if it wes presented a bit differently, people might actually /want/ to cooperate for a better gentoo, even if it's sometimes more work for them personally? That's all I'm saying. It's being made a whole lot less pleasant that it might be... for what reason? Just to satisfy someone's ego that they're right and can /force/ compliance? Yuck! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] supporting static-libs
On Tue, 2012-08-28 at 02:15 +0200, hasufell wrote: > Is there a reason not to support static-libs in an ebuild if the package > supports it? > > It seems some developers don't care about this option. What's the gentoo > policy on this? Isn't this actually a bug? For example, static linking is disabled in gtk+, pango, and gdk-pixbuf because they heavily rely on plugin loading. And anything that links to gtk+ should not be using static linking unless it wants to crash a lot.
Re: [gentoo-dev] supporting static-libs
On 27/08/2012 17:15, hasufell wrote: > Is there a reason not to support static-libs in an ebuild if the package > supports it? Most libtool software "supports" static-libs, because libtool let you build them, _but_ it might not be test or might not even work. One example is software that relies on plug-ins, such as xine-lib. or stuff that links to gmodule. Having static libraries there is technically possible, but if you do you have a bag full of problems and nothing else. > It seems some developers don't care about this option. What's the gentoo > policy on this? Isn't this actually a bug? I honestly don't usually put static-libs "just because" — if a case can be made about static libs to be useful, I'm always open to add an USE flag, but "because I can" is not an option for me. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] supporting static-libs
Is there a reason not to support static-libs in an ebuild if the package supports it? It seems some developers don't care about this option. What's the gentoo policy on this? Isn't this actually a bug?
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
Am Dienstag, 28. August 2012, 00:19:28 schrieb Michał Górny: > Right now, it just contains the function Tiziano listed in his post[1]. > I'd appreciate further ideas, feedback, and possibly an example from > someone who will actually need it. How about a function that just outputs the entire required dependency string? Such that we can (similar to add_kdebase_dep) write DEPEND="$(add_boost_dep)" (Probably we may want to pass parameters here for useflags and version, here's the doc for kdebase_dep from kde4-functions.eclass (and for boost we would not need a package name): # @FUNCTION: add_kdebase_dep # @DESCRIPTION: # Create proper dependency for kde-base/ dependencies. # This takes 1 to 3 arguments. The first being the package name, the optional # second is additional USE flags to append, and the optional third is the # version to use instead of the automatic version (use sparingly). # The output of this should be added directly to DEPEND/RDEPEND, and may be # wrapped in a USE conditional (but not an || conditional without an extra set # of parentheses). ) Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
On Mon, 27 Aug 2012 23:23:31 +0100
Ciaran McCreesh wrote:
> On Tue, 28 Aug 2012 00:19:28 +0200
> Michał Górny wrote:
> > + has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
>
> Until EAPI 5 is available with support for IUSE_IMPLICIT, if you 'use
> prefix', then prefix has to be listed in IUSE.
Great. Please report a bug, one for each existing eclass. I will copy
their solution then. Thank you.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
On Tue, 28 Aug 2012 00:19:28 +0200
Michał Górny wrote:
> + has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
Until EAPI 5 is available with support for IUSE_IMPLICIT, if you 'use
prefix', then prefix has to be listed in IUSE.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
Right now, it just contains the function Tiziano listed in his post[1].
I'd appreciate further ideas, feedback, and possibly an example from
someone who will actually need it.
---
gx86/eclass/boost-utils.eclass | 43 ++
1 file changed, 43 insertions(+)
create mode 100644 gx86/eclass/boost-utils.eclass
diff --git a/gx86/eclass/boost-utils.eclass b/gx86/eclass/boost-utils.eclass
new file mode 100644
index 000..b5a9f55
--- /dev/null
+++ b/gx86/eclass/boost-utils.eclass
@@ -0,0 +1,43 @@
+# Copyright 1999-2012 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: $
+
+if [[ ! ${_BOOST_ECLASS} ]]; then
+
+# @ECLASS: boost-utils.eclass
+# @MAINTAINER:
+# mgo...@gentoo.org
+# @BLURB: helper functions for packages using Boost C++ library
+# @DESCRIPTION:
+# Helper functions to be used when building packages using the Boost C++
+# library collection.
+
+case ${EAPI:-0} in
+ 0|1|2|3|4) ;;
+ *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
+esac
+
+inherit versionator
+
+# @FUNCTION: boost-utils_get_best_slot
+# @DESCRIPTION:
+# Get newest SLOT (major version) of Boost.
+boost-utils_get_best_slot() {
+ local pkg=dev-libs/boost
+ local atom=$(best_version ${pkg})
+ get_version_component_range 1-2 ${atom#${pkg}}
+}
+
+# @FUNCTION: boost-utils_get_includedir
+# @DESCRIPTION:
+# Get correct includedir for best Boost version. Outputs the sole path
+# (without -I).
+boost-utils_get_includedir() {
+ local slot=$(boost-utils_get_best_slot)
+ has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
+
+ echo -n "${EPREFIX}/usr/include/boost-${slot/./_}"
+}
+
+_BOOST_ECLASS=1
+fi # _BOOST_ECLASS
--
1.7.12
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-crypt/gpa: gpa-0.9.3.ebuild ChangeLog gpa-0.9.1_pre20100416-r1.ebuild
On Mon, 27 Aug 2012 11:28:45 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > >> not a problem for users of the official package manager. > > > > Cut it out. The Council makes the rules, not you, and the Council > > says that PMS, not what works with one particular Portage version, > > dictates what ebuilds can and cannot do. The whole "waah waah, I'm > > not only ignoring PMS, but I'm going to post to the mailing lists > > moaning about it" thing is getting old. > > Well, the whole argument is old, on both sides. I agree, PMS is > council blessed so gentoo devs shouldn't be moaning about it, but > OTOH, I can't always blame them, when the way it's used is often as a > club over the head that seems to appear out of nowhere and with no > explanation of WHY it's that way. That's not exactly the best way to > win friends and influence people, as they say, so a bit of moaning > over it isn't exactly surprising. No, you're utterly missing the point here. The spec is there to be followed, not battled and ignored unless a justification is provided at every step. When it comes to writing compliant ebuilds, PMS *is* the justification. One does not simply ignore the law because one does not like it or understand why it is the way it is. Now, if people are interested in why PMS says what it does in a particular, specific place, then that's something they're welcome to discuss in a separate thread. If the answers are generally found interesting then someone is welcome to produce an "annotated" PMS with historical commentary, a bit like the early C++ Annotated Reference Manual. However, this absolutely does not belong in "follow existing policy" threads. Simply put, developers are expected to follow the standard when developing. If there's something people don't understand or would like changed, it's entirely appropriate to talk about it as a separate issue, but PMS cannot be ignored in the mean time. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] adns & ares USE flags
Hello, $ quse -D adns ares global:adns: Adds support for the adns DNS client library local:ares:dev-libs/ecore: Enables support for asynchronous DNS using the net-dns/c-ares library local:ares:net-analyzer/wireshark: Use GNU net-dns/c-ares library to resolve DNS names local:ares:net-irc/znc: Enables support for asynchronous DNS using the c-ares library local:ares:net-misc/aria2: Enables support for asynchronous DNS using the c-ares library local:ares:net-misc/curl: Enabled c-ares dns support local:ares:net-p2p/gift: pull in Ares plugin Both of the flags (except for gift AFAICS) refer to asynchronous DNS resolution. Could we join them into one flag? I think we should retain 'adns', move appropriate 'ares' flags to it and modify the description to make it less library-centric. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-crypt/gpa: gpa-0.9.3.ebuild ChangeLog gpa-0.9.1_pre20100416-r1.ebuild
On 27/08/2012 00:18, Samuli Suominen wrote: > why leave the ebuild read $myconf from global scope? $EXTRA_ECONF works > for this Because extremely simply I forgot to delete the line. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] new vala.eclass
Third update; Alexis made a convincing argument that vala_pkg_setup
should be changed to vala_src_prepare.
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: vala.eclass
# @MAINTAINER:
# gn...@gentoo.org
# @AUTHOR:
# Alexandre Rostovtsev
# @BLURB: Sets up the environment for using a specific version of vala.
# @DESCRIPTION:
# This eclass sets up commonly used environment variables for using a specific
# version of dev-lang/vala to configure and build a package. It is needed for
# packages whose build systems assume the existence of certain unversioned vala
# executables, pkgconfig files, etc., which Gentoo does not provide.
#
# This eclass provides one phase function: src_prepare.
inherit multilib
case "${EAPI:-0}" in
0|1)
;;
*)
EXPORT_FUNCTIONS src_prepare
;;
esac
# @ECLASS-VARIABLE: VALA_API_VERSION
# @DEFAULT_UNSET
# @DESCRIPTION:
# Vala API version (e.g. 0.16).
# @FUNCTION: vala_src_prepare
# @DESCRIPTION:
# Sets up the environment variables and pkgconfig files for $VALA_API_VERSION.
vala_src_prepare() {
local p d valafoo
[[ ${VALA_API_VERSION} ]] || die "VALA_API_VERSION not set"
valafoo=$(type -P valac-${VALA_API_VERSION})
[[ ${valafoo} ]] && export VALAC="${valafoo}"
valafoo=$(type -P vala-${VALA_API_VERSION})
[[ ${valafoo} ]] && export VALA="${valafoo}"
valafoo=$(type -P vala-gen-introspect-${VALA_API_VERSION})
[[ ${valafoo} ]] && export VALA_GEN_INTROSPECT="${valafoo}"
valafoo=$(type -P vapigen-${VALA_API_VERSION})
[[ ${valafoo} ]] && export VAPIGEN="${valafoo}"
valafoo="${EPREFIX}/usr/share/vala/Makefile.vapigen"
[[ -e ${valafoo} ]] && export VAPIGEN_MAKEFILE="${valafoo}"
export VAPIGEN_VAPIDIR="${EPREFIX}/usr/share/vala/vapi"
mkdir -p "${T}/pkgconfig" || die "mkdir failed"
for p in libvala vapigen; do
for d in "${EPREFIX}/usr/$(get_libdir)/pkgconfig"
"${EPREFIX}/usr/share/pkgconfig"; do
if [[ -e ${d}/${p}-${VALA_API_VERSION}.pc ]]; then
ln -s "${d}/${p}-${VALA_API_VERSION}.pc"
"${T}/pkgconfig/${p}.pc" || die "ln failed"
break
fi
done
done
:
${PKG_CONFIG_PATH:="${EPREFIX}/usr/$(get_libdir)/pkgconfig:${EPREFIX}/usr/share/pkgconfig"}
export PKG_CONFIG_PATH="${T}/pkgconfig:${PKG_CONFIG_PATH}"
}
Re: [gentoo-dev] rfc: OpenRC network provides revisited
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/08/12 04:16 PM, William Hubbs wrote: > > The bottom line here is: I don't think all of the services we have > set up to "need net" in their default configuration should be set > up that way. It would make OpenRC work out of the box for many > more configurations. [ Snip! ] This is really more an idiology > thing I guess, but I think if you are tweeking a specific service > it should be done in the /etc/conf.d/service file. To follow the > example above, to make a particular service provide net, it is > better imo to put rc_provide="net" in /etc/conf.d/service. > > If you want to change this in rc.conf, use the > rc_[service]_[depend] variable instead of rc_[depend]. RC_[depend] > in rc.conf will apply that dependency to *all* services on your > system, including any new ones that get installed later, so be > absolutely sure you know what you are doing if you use this. I concurr with your analysis, just not your conclusions. :) I very much like (and depend on, in certain cases) the way depends on the 'net' service are set now, and would prefer they stay that way. Relatedly, since the only cases I'm aware of where it is desired for this to change are cases such as NFS-roots or vm's/containers where the 'net' service is up before openrc begins, to me this is a system-wide effect and not something that should be tweaked per-service. To change the default and then require per-service tweaks to get old behaviour back is imo not a particularly good idea. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlA7axoACgkQ2ugaI38ACPDAfAD/YpiHpAp2tMDhqBm5V19KTmwU BgavBXMATRcJeWETmV4A/1egNPg7i1pRpzWTLa7//Ano108rRQ9Ff9xZN01EBh1E =N0n2 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] new vala.eclass
On Mon, 27 Aug 2012 00:45:45 -0400 Alexandre Rostovtsev wrote: > On Sun, 2012-08-26 at 22:45 -0400, Alexis Ballier wrote: > > On Sun, 26 Aug 2012 19:43:32 -0400 > > Alexandre Rostovtsev wrote: > > > The variables that vala_pkg_setup sets are needed only at build > > > time. > > > > so it should be vala_src_prepare / unpack instead ? > > definitely not anything pkg_* imho > > IMHO src_prepare or src_unpack would be misleading because the > function does not modify the package's source and has nothing to do > with unpacking. it creates files as far as i understood the code; the point of vala.eclass is to prepare the environment for building the package, right ? you can probably get a valid point for a src_setup phase in a future eapi, but so far with current eapi, src_prepare seems the best choice > It's not an unusual idiom to set various environment > variables in pkg_setup even if those variables are relevant only at > build time; gnome-extra/zeitgeist and xfce4-vala/xfce4-vala are > typical examples that already export VALAC in their pkg_setup(). lots of bad examples does not make it good :) this is just wasted cpu cycles for binpkgs, moreover these two examples only set a variable and call type -P; the eclass does set a couple more of variables and writes to $T anyway its your call, but given that the eclass is only useful for building it seems bad practices to put its code in a pkg_ phase.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-crypt/gpa: gpa-0.9.3.ebuild ChangeLog gpa-0.9.1_pre20100416-r1.ebuild
Ciaran McCreesh posted on Mon, 27 Aug 2012 10:10:20 +0100 as excerpted: > On Mon, 27 Aug 2012 12:01:28 +0300 Samuli Suominen > wrote: >> On 27/08/12 10:25, Ciaran McCreesh wrote: >> > On Mon, 27 Aug 2012 10:18:17 +0300 Samuli Suominen >> > wrote: >> >> why leave the ebuild read $myconf from global scope? $EXTRA_ECONF >> >> works for this >> > >> > As far as ebuilds are concerned, there is no such thing as >> > EXTRA_ECONF. >> > >> > >> you mean to say PMS fails to document it? > > No, I mean to say that PMS was deliberately written to follow Gentoo > policy at the time it was written, which said that EXTRA_* is considered > to be there specifically for user use, and mustn't be used by ebuilds. The way I read it, that was the original point, that myconf was being included but was never set, so the only way it would be set if it were imported from the user's environment, and that wasn't necessary since the existing EXTRA_ECONF mechanism already handles that transparently to the ebuild. But maybe I'm reading it wrong... >> not a problem for users of the official package manager. > > Cut it out. The Council makes the rules, not you, and the Council says > that PMS, not what works with one particular Portage version, dictates > what ebuilds can and cannot do. The whole "waah waah, I'm not only > ignoring PMS, but I'm going to post to the mailing lists moaning about > it" thing is getting old. Well, the whole argument is old, on both sides. I agree, PMS is council blessed so gentoo devs shouldn't be moaning about it, but OTOH, I can't always blame them, when the way it's used is often as a club over the head that seems to appear out of nowhere and with no explanation of WHY it's that way. That's not exactly the best way to win friends and influence people, as they say, so a bit of moaning over it isn't exactly surprising. You're correct that ebuilds shouldn't be using EXTRA_ECONF as it's reserved for the user to use, but all you said was that ebuilds shouldn't use it, not why... until AFTER someone protested. Had you said WHY they shouldn't use it in your original post, adding all of one additional sentence, then the usage of PMS wouldn't have appeared to be a club out of nowhere, with no explanation. If that was done /consistently/ then people wouldn't have such sore noggins from being clubbed over the head all the time, and they'd probably react a lot more favorably to mentions of PMS. But I DO have to give you credit. There was a time when that information would have taken a dozen cycles of back and forth before the information was forthcoming. This time it was provided much sooner, one additional cycle instead of many, and you provided it immediately upon (not exactly friendly, I'll admit) request instead of forcing it to be extracted in some laborious process, so maybe you just overlooked providing the reason in the original post. Whatever, it's much improved over past behavior and you do get credit for that. Thanks. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-crypt/gpa: gpa-0.9.3.ebuild ChangeLog gpa-0.9.1_pre20100416-r1.ebuild
On Mon, 27 Aug 2012 12:01:28 +0300 Samuli Suominen wrote: > On 27/08/12 10:25, Ciaran McCreesh wrote: > > On Mon, 27 Aug 2012 10:18:17 +0300 > > Samuli Suominen wrote: > >> why leave the ebuild read $myconf from global scope? $EXTRA_ECONF > >> works for this > > > > As far as ebuilds are concerned, there is no such thing as > > EXTRA_ECONF. > > > > you mean to say PMS fails to document it? No, I mean to say that PMS was deliberately written to follow Gentoo policy at the time it was written, which said that EXTRA_* is considered to be there specifically for user use, and mustn't be used by ebuilds. > not a problem for users of the official package manager. Cut it out. The Council makes the rules, not you, and the Council says that PMS, not what works with one particular Portage version, dictates what ebuilds can and cannot do. The whole "waah waah, I'm not only ignoring PMS, but I'm going to post to the mailing lists moaning about it" thing is getting old. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-crypt/gpa: gpa-0.9.3.ebuild ChangeLog gpa-0.9.1_pre20100416-r1.ebuild
On 27/08/12 10:25, Ciaran McCreesh wrote: On Mon, 27 Aug 2012 10:18:17 +0300 Samuli Suominen wrote: why leave the ebuild read $myconf from global scope? $EXTRA_ECONF works for this As far as ebuilds are concerned, there is no such thing as EXTRA_ECONF. you mean to say PMS fails to document it? not a problem for users of the official package manager.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-crypt/gpa: gpa-0.9.3.ebuild ChangeLog gpa-0.9.1_pre20100416-r1.ebuild
On Mon, 27 Aug 2012 10:18:17 +0300 Samuli Suominen wrote: > why leave the ebuild read $myconf from global scope? $EXTRA_ECONF > works for this As far as ebuilds are concerned, there is no such thing as EXTRA_ECONF. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-crypt/gpa: gpa-0.9.3.ebuild ChangeLog gpa-0.9.1_pre20100416-r1.ebuild
On 27/08/12 04:52, Diego Petteno (flameeyes) wrote:
flameeyes12/08/27 01:52:43
Modified: ChangeLog
Added:gpa-0.9.3.ebuild
Removed: gpa-0.9.1_pre20100416-r1.ebuild
Log:
Version bump (thanks to Arfrever in bug #432636 for reporting). Simplify
thanks to EAPI 4 and fix bug #417437.
(Portage version: 2.2.0_alpha122/cvs/Linux x86_64)
Revision ChangesPath
1.80 app-crypt/gpa/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-crypt/gpa/ChangeLog?rev=1.80&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-crypt/gpa/ChangeLog?rev=1.80&content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-crypt/gpa/ChangeLog?r1=1.79&r2=1.80
Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/app-crypt/gpa/ChangeLog,v
retrieving revision 1.79
retrieving revision 1.80
diff -u -r1.79 -r1.80
--- ChangeLog 3 May 2012 18:16:38 - 1.79
+++ ChangeLog 27 Aug 2012 01:52:43 - 1.80
@@ -1,6 +1,13 @@
# ChangeLog for app-crypt/gpa
# Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/app-crypt/gpa/ChangeLog,v 1.79 2012/05/03
18:16:38 jdhore Exp $
+# $Header: /var/cvsroot/gentoo-x86/app-crypt/gpa/ChangeLog,v 1.80 2012/08/27
01:52:43 flameeyes Exp $
+
+*gpa-0.9.3 (27 Aug 2012)
+
+ 27 Aug 2012; Diego E. Pettenò +gpa-0.9.3.ebuild,
+ -files/gpa-desktop-file-validate-new.patch, -gpa-0.9.1_pre20100416-r1.ebuild:
+ Version bump (thanks to Arfrever in bug #432636 for reporting). Simplify
+ thanks to EAPI 4 and fix bug #417437.
03 May 2012; Jeff Horelick gpa-0.9.1_pre20100416.ebuild,
gpa-0.9.1_pre20100416-r1.ebuild:
1.1 app-crypt/gpa/gpa-0.9.3.ebuild
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-crypt/gpa/gpa-0.9.3.ebuild?rev=1.1&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/app-crypt/gpa/gpa-0.9.3.ebuild?rev=1.1&content-type=text/plain
Index: gpa-0.9.3.ebuild
===
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/app-crypt/gpa/gpa-0.9.3.ebuild,v 1.1
2012/08/27 01:52:43 flameeyes Exp $
EAPI=4
DESCRIPTION="The GNU Privacy Assistant (GPA) is a graphical user interface for
GnuPG"
HOMEPAGE="http://gpa.wald.intevation.org";
SRC_URI="mirror://gnupg/${PN}/${P}.tar.bz2"
LICENSE="GPL-3"
SLOT="0"
KEYWORDS="~alpha ~amd64 ~ppc ~ppc64 ~sparc ~x86"
IUSE="nls"
RDEPEND=">=x11-libs/gtk+-2.10.0:2
>=dev-libs/libgpg-error-1.4
>=dev-libs/libassuan-1.1.0
>=app-crypt/gnupg-2
>=app-crypt/gpgme-1.2.0"
DEPEND="${RDEPEND}
virtual/pkgconfig
nls? ( sys-devel/gettext )"
src_configure() {
# force --libexecdir so that it doesn't expand to
# ${exec_prefix}/libexec instead.
econf \
--libexecdir=/usr/libexec \
--with-gpgme-prefix=/usr \
--with-libassuan-prefix=/usr \
$(use_enable nls) \
${myconf}
}
why leave the ebuild read $myconf from global scope? $EXTRA_ECONF works
for this
