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

[Ciaran McCreesh]

On Mon, 27 Aug 2012 11:28:45 +0000 (UTC)
Duncan <1i5t5.duncan@×××.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