On 04/27/2012 07:27 AM, Ciaran McCreesh wrote:
> On Fri, 27 Apr 2012 14:15:35 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>> In ordered to make it globally available, it cannot simply be an
>> EAPI-5 thing, it must apply to all current ebuilds whether they (or
>> an inherited eclass) call epatch_user or not. Which means that
>> conflict with the existing epatch_user is unavoidable, since it will
>> either try to run twice where it's already called, or it won't run at
>> all where it's not.
>
> In order to make it globally available, you put it in EAPI 5, and make
> the package mangler die at pretend time if the user has patches
> specified for a package that isn't EAPI 5.

Or, have repoman assert that src_prepare contains an epatch_user call if
EAPI is less than 5.
--
Thanks,
Zac

On Fri, 27 Apr 2012 08:41:35 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> > In order to make it globally available, you put it in EAPI 5, and
> > make the package mangler die at pretend time if the user has patches
> > specified for a package that isn't EAPI 5.
>
> Or, have repoman assert that src_prepare contains an epatch_user call
> if EAPI is less than 5.

Why bother? That's hideously error prone. We have a simple way that's
guaranteed to work, and that is able to inform the user if their
expectations can't be met.

--
Ciaran McCreesh

On 27/04/12 17:15, Duncan wrote:

Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted:

Having the package manager interact with an eclass function like
epatch_user is ugly, and it's unnecessary since we can pull all of the
pieces into the package manager in EAPI 5. Any eclasses that currently
call epatch_user can have a conditional like this:

if has $EAPI 0 1 2 3 4 ; then
epatch_user
else
apply_user_patches_here
fi


But that doesn't solve the problem of making it globally available, since
it only applies to packages/eclasses that already call epatch_user for
EAPIs thru current EAPI-4.

In ordered to make it globally available, it cannot simply be an EAPI-5
thing, it must apply to all current ebuilds whether they (or an inherited
eclass) call epatch_user or not. Which means that conflict with the
existing epatch_user is unavoidable, since it will either try to run
twice where it's already called, or it won't run at all where it's not.


According to the source, calling it twice is perfectly safe.

On 04/27/2012 08:45 AM, Ciaran McCreesh wrote:
> On Fri, 27 Apr 2012 08:41:35 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>>> In order to make it globally available, you put it in EAPI 5, and
>>> make the package mangler die at pretend time if the user has patches
>>> specified for a package that isn't EAPI 5.
>>
>> Or, have repoman assert that src_prepare contains an epatch_user call
>> if EAPI is less than 5.
>
> Why bother? That's hideously error prone. We have a simple way that's
> guaranteed to work, and that is able to inform the user if their
> expectations can't be met.

I suppose that we could do it both ways. The repoman check would be for
people who want a practical approach that doesn't require all ebuilds to
be converted to EAPI 5, and your strict die approach would be for people
who want strictness and can afford to wait for the relevant ebuilds to
be converted to EAPI 5.
--
Thanks,
Zac

On Fri, 27 Apr 2012 08:55:49 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> I suppose that we could do it both ways. The repoman check would be
> for people who want a practical approach that doesn't require all
> ebuilds to be converted to EAPI 5, and your strict die approach would
> be for people who want strictness and can afford to wait for the
> relevant ebuilds to be converted to EAPI 5.

But there's no way the repoman check is going to give anything like
reliable answers if you're involving eclasses...

--
Ciaran McCreesh

On 04/27/2012 09:00 AM, Ciaran McCreesh wrote:
> On Fri, 27 Apr 2012 08:55:49 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> I suppose that we could do it both ways. The repoman check would be
>> for people who want a practical approach that doesn't require all
>> ebuilds to be converted to EAPI 5, and your strict die approach would
>> be for people who want strictness and can afford to wait for the
>> relevant ebuilds to be converted to EAPI 5.
>
> But there's no way the repoman check is going to give anything like
> reliable answers if you're involving eclasses...

Okay, so people who need "reliable answers" can go with your strict
approach. Meanwhile, it's relatively easy to to a manual audit of the
src_prepare function of each eclass.
--
Thanks,
Zac

On Fri, 27 Apr 2012 09:08:06 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> > But there's no way the repoman check is going to give anything like
> > reliable answers if you're involving eclasses...
>
> Okay, so people who need "reliable answers" can go with your strict
> approach. Meanwhile, it's relatively easy to to a manual audit of the
> src_prepare function of each eclass.

Providing unreliable functionality just leads to whining and
contortions when it doesn't work. This isn't a situation where
compromise is necessary, so there's no reason not to just do it
properly.

--
Ciaran McCreesh

On 04/27/2012 09:11 AM, Ciaran McCreesh wrote:
> On Fri, 27 Apr 2012 09:08:06 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>>> But there's no way the repoman check is going to give anything like
>>> reliable answers if you're involving eclasses...
>>
>> Okay, so people who need "reliable answers" can go with your strict
>> approach. Meanwhile, it's relatively easy to to a manual audit of the
>> src_prepare function of each eclass.
>
> Providing unreliable functionality just leads to whining and
> contortions when it doesn't work. This isn't a situation where
> compromise is necessary, so there's no reason not to just do it
> properly.

Yeah, I guess you're right. ;-)
--
Thanks,
Zac

On 04/27/2012 07:20 AM, Michał Górny wrote:
> We could finally decide it'll be a Portage internal feature, and modify
> epatch_user() to export some Portage-specific indication that user
> patches were applied.

Since we've managed to survive up to this point without such a feature,
I think it's worth the wait roll it into EAPI 5 and have a clean
solution that doesn't rely on package manager interaction with eclasses.
If we quickly draft an EAPI 5 spec, there's still have time to have it
approved at the next council meeting.
--
Thanks,
Zac

>>>>> On Fri, 27 Apr 2012, Zac Medico wrote:

> Since we've managed to survive up to this point without such a
> feature, I think it's worth the wait roll it into EAPI 5 and have a
> clean solution that doesn't rely on package manager interaction with
> eclasses. If we quickly draft an EAPI 5 spec, there's still have
> time to have it approved at the next council meeting.

Did I get it right, you are thinking about a special EAPI only for
user patches? I'd say that the feature is not important enough to
justify that.

Ulrich