Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

Making user patches globally available

 

 

First page Previous page 1 2 3 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded


ulm at gentoo

Apr 27, 2012, 11:01 AM

Post #51 of 60 (245 views)
Permalink
Re: Re: Making user patches globally available [In reply to]

>>>>> 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


zmedico at gentoo

Apr 27, 2012, 11:10 AM

Post #52 of 60 (246 views)
Permalink
Re: Re: Making user patches globally available [In reply to]

On 04/27/2012 11:01 AM, Ulrich Mueller wrote:
>>>>>> 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.

Let's just say that it's within the realm of possibilities, and I
consider it to be preferable to a solution which involves package
manager interaction with epatch_user.
--
Thanks,
Zac


antarus at gentoo

Apr 27, 2012, 11:42 AM

Post #53 of 60 (248 views)
Permalink
Re: Re: Making user patches globally available [In reply to]

On Fri, Apr 27, 2012 at 11:01 AM, Ulrich Mueller <ulm [at] gentoo> wrote:
>>>>>> 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.

Release early and often :)

>
> Ulrich
>


mgorny at gentoo

Apr 27, 2012, 11:57 AM

Post #54 of 60 (245 views)
Permalink
Re: Re: Making user patches globally available [In reply to]

On Fri, 27 Apr 2012 20:01:15 +0200
Ulrich Mueller <ulm [at] gentoo> wrote:

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

+1. Either we use EAPIs with some thinking or just drop that concept
and move on to something else.

There is a number of features waiting for new EAPI, and noone yet even
considered them. But when it comes to marginal feature which many of
devs don't even accept, it's enough to quickly release a new EAPI which
most of the tree won't support.

--
Best regards,
Michał Górny
Attachments: signature.asc (0.31 KB)


zmedico at gentoo

Apr 27, 2012, 12:26 PM

Post #55 of 60 (249 views)
Permalink
Re: Re: Making user patches globally available [In reply to]

On 04/27/2012 11:57 AM, Michał Górny wrote:
> On Fri, 27 Apr 2012 20:01:15 +0200
> Ulrich Mueller <ulm [at] gentoo> wrote:
>
>>>>>>> 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.
>
> +1. Either we use EAPIs with some thinking or just drop that concept
> and move on to something else.
>
> There is a number of features waiting for new EAPI, and noone yet even
> considered them. But when it comes to marginal feature which many of
> devs don't even accept, it's enough to quickly release a new EAPI which
> most of the tree won't support.

The fact that it's a "marginal feature" is exactly why I don't think it
justifies adding a quick and dirty hack that introduces an interaction
between the package manager an eclass function like epatch_user.

On the other hand, if it's important enough to justify a quick and dirty
hack in the package manager, then I'd argue that it's also important
enough to justify a quick and clean EAPI bump.
--
Thanks,
Zac


ciaran.mccreesh at googlemail

Apr 27, 2012, 12:26 PM

Post #56 of 60 (248 views)
Permalink
Re: Re: Making user patches globally available [In reply to]

On Fri, 27 Apr 2012 20:01:15 +0200
Ulrich Mueller <ulm [at] gentoo> 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.

Didn't we have a few other cheap things lined up?

--
Ciaran McCreesh
Attachments: signature.asc (0.19 KB)


ulm at gentoo

Apr 27, 2012, 12:43 PM

Post #57 of 60 (248 views)
Permalink
Re: Re: Making user patches globally available [In reply to]

>>>>> On Fri, 27 Apr 2012, Ciaran McCreesh wrote:

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

> Didn't we have a few other cheap things lined up?

Yes we do, and IMHO it would make much more sense if EAPI 5 would
include them.

(And of course, there are still the two features that were omitted
from EAPI 4, namely slot-operator-deps and profile-iuse-injection.)

Ulrich


mgorny at gentoo

Apr 27, 2012, 12:58 PM

Post #58 of 60 (246 views)
Permalink
Re: Re: Making user patches globally available [In reply to]

On Fri, 27 Apr 2012 21:43:06 +0200
Ulrich Mueller <ulm [at] gentoo> wrote:

> >>>>> On Fri, 27 Apr 2012, Ciaran McCreesh wrote:
>
> >> 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.
>
> > Didn't we have a few other cheap things lined up?
>
> Yes we do, and IMHO it would make much more sense if EAPI 5 would
> include them.
>
> (And of course, there are still the two features that were omitted
> from EAPI 4, namely slot-operator-deps and profile-iuse-injection.)

Of course, if we take the 'quick EAPI 5 route', it won't include
anything useful. In the meantime, do we have a complete list of
candidates for EAPI 5?

--
Best regards,
Michał Górny
Attachments: signature.asc (0.31 KB)


slong at rathaus

Apr 27, 2012, 5:28 PM

Post #59 of 60 (251 views)
Permalink
Re: Re: Making user patches globally available [In reply to]

Zac Medico wrote:
> Steven J Long wrote:
>> It seems there's two major cases, with autotools or without. In either
>> case, epatch_user should be called after Gentoo patches have been
>> applied.
>>
>> Why not make epatch_user set a variable to indicate that patches have
>> been applied, and only apply the patches on the first call?
>>
>> Then eautoreconf could call it before calling autoconf (and the ebuild
>> wouldn't need to worry about it.) And any custom src_prepare function
>> could call it when needed, if it needed to be done during the phase, and
>> not after.
>>
>> After src_prepare, the PM could just call it unconditionally, since it
>> will not apply the patches again, if it's already been called by the
>> ebuild.
>>
>> Does that make sense?
>
> Yeah, sounds roughly equivalent to Ciaran's suggested
> "apply_user_patches_here" approach [1], except that Ciaran suggested to
> make it an error if src_prepare doesn't call apply_user_patches_here (so
> people don't forget to call it when they should).
>
> [1]
> http://archives.gentoo.org/gentoo-
dev/msg_c228be85e0c4e577ad194e6004d59062.xml

Yeah, I saw that, but given that this would be standardisation around an
EAPI bump, I don't see the point in changing the name of the function to
mean exactly the same thing, only to make it much more inconvenient in
usage.

I feel there needs to be more thinking about what you mentioned, ie around
the lines of "user-patches are applied on top of Gentoo-patched sources."
This makes much more sense in process terms, since user-patches are more
likely to be included in Gentoo-patches, and thus easier to handle for
submission upstream. The alternative (user-patches applied to vanilla
sources) has much more likelihood for bad interaction with Gentoo patches or
changes.

If we stipulate that src_prepare transforms upstream sources into Gentoo-
official sources, then it only makes sense to epatch_user thereafter, and
there's no point burdening the ebuild, or its developer, with that task.
It also makes ebuilds much cleaner to read.

Where you have a build-system that requires epatch_user part way through
src_prepare, it's up to the ebuild, or more likely eclass for that build-
system, to call it at the appropriate time. (autoconf ebuilds clearly should
just inherit whatever eclass the team tells them to, and stop messing
around.)

In any event, specifying that the PM only calls epatch_user after
src_prepare if there are user-patches, and it hasn't been called already
(this is easiest done within epatch_user, ofc) allows ebuild or eclass
developers to override the default easily, while still keeping things easy
for most ebuilds.

eg: so far I've heard that: epatch_user && eautoreconf
..is desired behaviour, so I guess you want logic like:

if ((${#USER_PATCHES[*]})); then
((applied_user_patches)) || {
<.. apply the patches || die ..>
applied_user_patches=1
}
return 0
else return 1
fi

Given something like the above, the addition of a simple[1]: epatch_user
..to eautoreconf before the call to autoreconf, and after src_prepare in
ebuild.sh, cannot do any harm, and ensures that sources are patched without
adding any cruft to ebuilds.

I also think there would be merit in optionally including any user-patches
with binpkgs. This would be useful for transparency, ie debugging and
licensing concerns with respect to modified sources.

Regards,
Steve.

PS As you know, ofc, patches against vanilla sources can be done in a
pre_src_prepare bashrc hook, if one really has to for custom builds. I don't
think anyone's talking about implementing them; or should they be on the
table too?

[1] Yes, EAPI-dependent, so might need eg:
case $EAPI in 5|6) epatch_user;; esac
..depending on what else is happening, but simple in the sense that we don't
care about its return value in these contexts.

--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)


1i5t5.duncan at cox

Apr 27, 2012, 7:29 PM

Post #60 of 60 (247 views)
Permalink
Re: Making user patches globally available [In reply to]

Nikos Chantziaras posted on Fri, 27 Apr 2012 18:55:12 +0300 as excerpted:

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

That's actually one of the points I've been making, that if we simply
force an epatch_user at approximately post_src_prepare, the existing code
already deals with multiple calls just fine.

The problem appears if we then decide that we're going to do something
with eautoreconf immediately thereafter.

* if we just call it, we're potentially doing extra work both when the
patch didn't require it, and when the ebuild already invoked eautoreconf
after doing its own patching.

* elif we try to somehow detect that it needs to be run, that's a huge
amount of additional complexity we're now talking about adding to what
WAS a simple globalization of already tested working code.

* elif we try to force developers to call it at some point via repoman
check or the like, thus letting them decide, then we're possibly looking
at eapi5, and in any case, we just lost the point of the entire exercise,
to make it global without forcing a touch of every existing ebuild in the
tree that doesn't do it yet.

Rock, hard place, with us between them!

That's why I proposed up-thread that at least for now we go with the
simple option, simply have the PM call epatch_user (either supplying its
own internal function or sourcing the eclass to get the existing eclass
version), and just punt on the eautoreconf stuff for now. As I said
there, based on my experience anyway, that covers the for me at least
80-90% of use-cases where the patch isn't complex enough to require an
eautoreconf, using code that's already known to be solid and well
tested. For the remaining 10-20%, the old solution, copying the ebuild
to an overlay and adding the patch calls and any other necessary
modifications manually, still works.

I'd rather take the "good solution", the well tested code we have now,
and apply it globally, yielding the 80-90% reduction in forced personal
overlay ebuilds as a result, and continue to deal with the 10-20% than
need eautoreconf or other processing manually, now, instead of waiting
possibly forever for a "perfect" solution that might or might not ever
come, even if in theory it could raise that 80-90% to 99%+.

But Zac and a few others believe that what I called the "good" solution
will result in a more or less continuous flood of bugs from people who
expect epatch_user (or whatever replaces it) to "just work" for that
perhaps 10-20% where eautoreconf is required as well, and don't believe
it's an acceptable tradeoff. Since they're the devs dealing with the
bugs, not me, that's a trump card I can't counter. They win.
Unfortunately that means we're stuck waiting for a "perfect" solution
that may never come, once again, or at least with an eapi5 solution that
even when adopted won't reach global coverage for many many years to
come. Oh, well...

Unless you're talking about eautoreconf, not epatch_user. Actually,
calling eautoreconf extra times should be safe. It'll just take longer,
potentially MUCH longer, relative to the current merge time of some
affected packages.

(There's the question too, of what happens if eautoreconf is called on a
non-autotools package. But at a suitably high level, that simply gets
lumped in with the general robustness question on the whole approach.)

--
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

First page Previous page 1 2 3 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.