Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'

[Chip Parker <infowolfe@gmail.com>]

On Sat, Aug 22, 2009 at 5:32 PM, David Leverton<levertond@googlemail.com> wrote:
> On Sunday 23 August 2009 01:26:24 Chip Parker wrote:
>> So, Ciaran, if your personal reference implementation of PMS fails
>> miserably when using this methodology, your argument that I won't be
>> or "am not" affected by your attempt at changing portage is invalid.
>> If you'd like to test for yourself, I'll be more than happy to tar up
>> both my /etc/paludis and /etc/managed-portage for you.
>
> You're still talking about /etc, which is still unaffected by PMS.  If Paludis
> doesn't support a feature in /etc that you want to use, then feel free to
> file a bug.  If Portage supports that feature in /etc, there's no reason why
> it needs to stop doing so, regardless of what it does or doesn't accept in
> the tree.

They're the same thing. It doesn't matter if the profiles directory is
in located in /tmp or in /usr/local/portage, the behavior of paludis
*still* doesn't support the feature that these profiles depend on and
portage still *HAS* since before PMS was submitted to this list as an
RFC in August of 2006. The argument here is that PMS should be changed
to reflect what has been being used "in the wild" since before it came
into existence, especially considering the removal of the particular
feature that this "trick" depends on would break user expected
behavior.

On Sat, Aug 22, 2009 at 5:34 PM, Ciaran
McCreesh<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 22 Aug 2009 17:26:24 -0700
> Chip Parker <infowolfe@gmail.com> wrote:
>> Since you have a habit of ignoring relevant bits of technical
>> opposition to some of your more insane schemes, I'll cite *again* the
>> relevant portion.
>
> I showed you the relevant portion. /etc/make.profile means it is user
> configuration, which in turn means PMS has absolutely nothing to say
> about it. Anything done under /etc/make.profile is entirely up to the
> package manager and is not covered by the specification.
>
> So for the fourth time, no-one has asked for anything that will break
> what you're doing.

You claim that PMS doesn't matter outside of a repository, and yet it
most certainly does, because as I said to David, it doesn't matter
/where/ the profiles are actually located: /etc/, /tmp/,
/usr/local/portage/, or /usr/portage/ the behavior *should* be both
consistent and not unnecessarily restricted by a specification
controlled by a person who is on the outside of the Gentoo
organization. If you'd prefer, I can merge my /etc/managed-portage
stuff with my internal overlay and then bitch loudly about you
attempting to remove features that existed prior to your involvement
in Gentoo's package managers. Additionally, there isn't a way to
define in paludis where the profiles actually exist outside of the
repository configuration files, which means that in your mind, they're
one and the same.

What you proposed in the bug you filed would specifically break how I
do things, without replacing it with an equal or better solution. Your
inability or unwillingness to comprehend that simple fact is really
not my concern.

When the most prolific committer to PMS also happens to the most
prolific committer and is listed as "owning" the repository for a
competing package manager, it looks suspiciously like conflict of
interest.