On Mon, Aug 4, 2008 at 4:11 PM, Ciaran McCreesh
<ciaran.mccreesh@...> wrote:
> On Mon, 4 Aug 2008 16:06:11 -0700
> "Alec Warner" <antarus@g.o> wrote:
>> On Mon, Aug 4, 2008 at 11:29 AM, Stephen Bennett
>> <spbennett@...> wrote:
>> > I would like to put forward the following suggestion for the
>> > Council's consideration:
>> >
>> > "While the current state of PMS is not perfect, it is a reasonably
>> > close approximation to existing and historical behaviour of EAPI 0.
>> > Given this, and that getting a perfect definition is not feasible
>> > on a timescale shorter than several years, it should be treated as
>> > a draft standard, and any deviations from it found in the gentoo
>> > tree or package managers should have a bug filed against either the
>> > deviator or PMS to resolve the differences.
>>
>> Is this not already the status quo?  Surely a number of bugs in the
>> tree have already been fixed in this manner.
>
> Currently some developers are quite happy to fix issues, whilst others
> prefer to yell "Portage is the only supported package manager and if it
> works for me with Portage you can go to hell"...

So assuming the council says we should fix all these issues (and in
most cases I would support that assertion)
who would fix them?  The maintainer is obviously hostile and I doubt
the council is going to *force* them to accept said
patches.  Is QA going to fix these bugs?

>
> Also, some developers seem quite happy making changes to Portage that
> break existing packages that rely upon behaviour as defined by PMS,
> under the assertion that "PMS is too much like a rulebook"...

Also some developers seem quite happy making changes to PMS that break
existing packages
that rely upon behavior as defined by Portage; under the assertion
that "Portage is a broken/buggy piece of software"

That being said you are free to chat to Zac about the changes; I doubt
you can compel him to comply with PMS
100% unless this is driven by developers themselves.  He (not unlike
me) is kind of a pragmatic fellow.

-Alec

>
> --
> Ciaran McCreesh
>