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:

flameeyes 12/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 Changes Path
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 -0000 1.79
+++ ChangeLog 27 Aug 2012 01:52:43 -0000 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ò <flameeyes@gentoo.org> +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 <jdhore@gentoo.org> 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

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 <ssuominen@gentoo.org> 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

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 <ssuominen@gentoo.org> 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.

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 <ssuominen@gentoo.org> wrote:
> On 27/08/12 10:25, Ciaran McCreesh wrote:
> > On Mon, 27 Aug 2012 10:18:17 +0300
> > Samuli Suominen <ssuominen@gentoo.org> 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

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
> <ssuominen@gentoo.org> wrote:
>> On 27/08/12 10:25, Ciaran McCreesh wrote:
>> > On Mon, 27 Aug 2012 10:18:17 +0300 Samuli Suominen
>> > <ssuominen@gentoo.org> 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

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

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 +0000 (UTC)
Duncan <1i5t5.duncan@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

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

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.duncan@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-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.duncan@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