On Wed, 21 Oct 2015 01:24:00 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> Alexis Ballier posted on Tue, 20 Oct 2015 12:25:07 +0200 as excerpted:
>
> > On Tue, 20 Oct 2015 06:00:15 -0400 Rich Freeman
> > wrote:
> >
> >> So, perhaps it is a fair question to ask what is the specific harm
>
On Tue, 20 Oct 2015 06:00:15 -0400
Rich Freeman wrote:
[...]
> >
> > First, eclasses shouldn't apply patches on their own but take what
> > the ebuild tells it to apply: With multiple eclasses applying random
> > patches on their own, you're already asking for trouble.
> > Then, ebuild can just se
On Tue, Oct 20, 2015 at 5:22 AM, Alexis Ballier wrote:
>
> Ok, that's what I'd call "forced correctness" :)
> But again, theory tells you that if you want algorithmically checkable
> correctness then you have to seriously limit your possibilities, which
> is why I usually don't even consider this
On Tue, 20 Oct 2015 04:57:07 -0400
Rich Freeman wrote:
> On Tue, Oct 20, 2015 at 3:51 AM, Alexis Ballier
> wrote:
> > On Mon, 19 Oct 2015 15:49:06 -0400
> > Rich Freeman wrote:
> >
> > It's not about correctness vs convenience: eapply_user idempotent
> > doesn't prevent from doing it correctly.
On Tue, Oct 20, 2015 at 3:51 AM, Alexis Ballier wrote:
> On Mon, 19 Oct 2015 15:49:06 -0400
> Rich Freeman wrote:
>
> It's not about correctness vs convenience: eapply_user idempotent
> doesn't prevent from doing it correctly. It makes it possible to do it
> incorrectly though, just like any turi
On Tue, 20 Oct 2015 00:47:49 -0700
Daniel Campbell wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 10/17/2015 05:52 AM, Ulrich Mueller wrote:
> >> On Sat, 17 Oct 2015, hasufell wrote:
> >
> >>> 2. eapply_user really belongs in the PM, especially if it's run
> >>> by d
On Mon, 19 Oct 2015 15:49:06 -0400
Rich Freeman wrote:
> On Mon, Oct 19, 2015 at 2:28 PM, Alexis Ballier
> wrote:
> >
> > However, as you say, putting it in cmake-utils needs to be properly
> > thought so that it doesn't conflict with other eclasses: Hence the
> > need to properly define what ec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/17/2015 05:52 AM, Ulrich Mueller wrote:
>> On Sat, 17 Oct 2015, hasufell wrote:
>
>>> 2. eapply_user really belongs in the PM, especially if it's run
>>> by default. And it needs patch applying function. And if we
>>> have to implement pa
Am Montag, 19. Oktober 2015, 09:58:34 schrieb Michał Górny:
>
> Why do you assume I overlooked something? I thought exactly of this
> case, and decide that will force developers to finally write sane
> eclasses.
>
Can we adapt the gravitational constant of the universe for this special case
too,
On Mon, Oct 19, 2015 at 2:28 PM, Alexis Ballier wrote:
>
> However, as you say, putting it in cmake-utils needs to be properly
> thought so that it doesn't conflict with other eclasses: Hence the need
> to properly define what eclasses should call eapply_user and apply
> patches and what should no
On Mon, 19 Oct 2015 13:17:13 -0400
Rich Freeman wrote:
> On Mon, Oct 19, 2015 at 10:21 AM, Alexis Ballier
> wrote:
> > On Mon, 19 Oct 2015 09:51:20 -0400
> > Rich Freeman wrote:
> > [...]
> >> >
> >> >> I'd say the best approach for compatibility if you have an
> >> >> existing eclass and i
On Mon, Oct 19, 2015 at 10:21 AM, Alexis Ballier wrote:
> On Mon, 19 Oct 2015 09:51:20 -0400
> Rich Freeman wrote:
> [...]
>> >
>> >> I'd say the best approach for compatibility if you have an existing
>> >> eclass and it already exports src_prepare is to not call
>> >> eapply_user unless it firm
On Mon, 19 Oct 2015 09:51:20 -0400
Rich Freeman wrote:
[...]
> >
> >> I'd say the best approach for compatibility if you have an existing
> >> eclass and it already exports src_prepare is to not call
> >> eapply_user unless it firmly falls into the #2 category above.
> >
> > Replace 'not call
(To avoid repeating the same exception over and over, please
understand that nothing said below is intended to apply to the
do-everything eclasses used by KDE/etc, where the eclass and ebuilds
are carefully maintained in conjunction with each other.)
On Mon, Oct 19, 2015 at 9:34 AM, Alexis Ballier
On Mon, 19 Oct 2015 08:38:49 -0400
Rich Freeman wrote:
> On Mon, Oct 19, 2015 at 3:12 AM, Alexis Ballier
> wrote:
> > But there is something important we've overlooked: should eclasses
> > that export src_prepare call eapply_user ? I think yes, otherwise
> > they'd make packages inheriting them
On Mon, Oct 19, 2015 at 3:12 AM, Alexis Ballier wrote:
> But there is something important we've overlooked: should eclasses that
> export src_prepare call eapply_user ? I think yes, otherwise they'd
> make packages inheriting them violate the 'at least once rule'.
This sort of thing has been disc
On Mon, 19 Oct 2015 10:25:29 +0200
Ulrich Mueller wrote:
> > On Mon, 19 Oct 2015, Anthony G Basile wrote:
>
> > Why can't you just do something like this in the implementation of
> > eapply_user()? I must be missing some subtle point.
>
> > foo() {
> > if [[ -z $DONE ]]; then
> On Mon, 19 Oct 2015, Anthony G Basile wrote:
> Why can't you just do something like this in the implementation of
> eapply_user()? I must be missing some subtle point.
> foo() {
> if [[ -z $DONE ]]; then
> DONE="all done"
> echo "in foo"
>
On Mon, 19 Oct 2015 10:09:41 +0200
Michał Górny wrote:
> On Mon, 19 Oct 2015 10:04:22 +0200
> Alexis Ballier wrote:
>
> > On Mon, 19 Oct 2015 09:58:34 +0200
> > Michał Górny wrote:
> >
> > > On Mon, 19 Oct 2015 09:12:43 +0200
> > > Alexis Ballier wrote:
> > >
> > > > On Sun, 18 Oct 20
On Mon, 19 Oct 2015 10:04:22 +0200
Alexis Ballier wrote:
> On Mon, 19 Oct 2015 09:58:34 +0200
> Michał Górny wrote:
>
> > On Mon, 19 Oct 2015 09:12:43 +0200
> > Alexis Ballier wrote:
> >
> > > On Sun, 18 Oct 2015 12:17:58 +0200
> > > Ulrich Mueller wrote:
> > >
> > > > > On Sun, 1
On 10/19/15 3:58 AM, Michał Górny wrote:
On Mon, 19 Oct 2015 09:12:43 +0200
Alexis Ballier wrote:
On Sun, 18 Oct 2015 12:17:58 +0200
Ulrich Mueller wrote:
On Sun, 18 Oct 2015, Michał Górny wrote:
On Sun, 18 Oct 2015 11:54:40 +0200
Ulrich Mueller wrote:
So the question is if we sh
On Mon, 19 Oct 2015 09:58:34 +0200
Michał Górny wrote:
> On Mon, 19 Oct 2015 09:12:43 +0200
> Alexis Ballier wrote:
>
> > On Sun, 18 Oct 2015 12:17:58 +0200
> > Ulrich Mueller wrote:
> >
> > > > On Sun, 18 Oct 2015, Michał Górny wrote:
> > >
> > > > On Sun, 18 Oct 2015 11:54:
On Mon, 19 Oct 2015 09:12:43 +0200
Alexis Ballier wrote:
> On Sun, 18 Oct 2015 12:17:58 +0200
> Ulrich Mueller wrote:
>
> > > On Sun, 18 Oct 2015, Michał Górny wrote:
> >
> > > On Sun, 18 Oct 2015 11:54:40 +0200
> > > Ulrich Mueller wrote:
> >
> > >> So the question is if we
On Mon, 19 Oct 2015 03:22:37 -0400
"Anthony G. Basile" wrote:
> On 10/19/15 3:12 AM, Alexis Ballier wrote:
> > On Sun, 18 Oct 2015 12:17:58 +0200
> > Ulrich Mueller wrote:
> >
> >>> On Sun, 18 Oct 2015, Michał Górny wrote:
> >>> On Sun, 18 Oct 2015 11:54:40 +0200
> >>> Ulrich Mueller wr
On 10/19/15 3:12 AM, Alexis Ballier wrote:
On Sun, 18 Oct 2015 12:17:58 +0200
Ulrich Mueller wrote:
On Sun, 18 Oct 2015, Michał Górny wrote:
On Sun, 18 Oct 2015 11:54:40 +0200
Ulrich Mueller wrote:
So the question is if we should add a sentence like the following
to the spec:
In EAPIs wher
On Sun, 18 Oct 2015 12:17:58 +0200
Ulrich Mueller wrote:
> > On Sun, 18 Oct 2015, Michał Górny wrote:
>
> > On Sun, 18 Oct 2015 11:54:40 +0200
> > Ulrich Mueller wrote:
>
> >> So the question is if we should add a sentence like the following
> >> to the spec:
> >>
> >> In EAPIs where
On Sun, 18 Oct 2015 19:36:09 +0100
Ciaran McCreesh wrote:
> On Sun, 18 Oct 2015 20:19:12 +0200
> Alexis Ballier wrote:
> > what I was trying to understand is what is the usefulness of eapply
> > vs epatch
>
> The point of eapply is that it's inside the package manager, so it can
> safely be u
On Sun, 18 Oct 2015 20:19:12 +0200
Alexis Ballier wrote:
> what I was trying to understand is what is the usefulness of eapply
> vs epatch
The point of eapply is that it's inside the package manager, so it can
safely be used by default phase functions, for user patches, etc.
Rather than it being
On Sun, 18 Oct 2015 19:06:33 +0100
Ciaran McCreesh wrote:
> On Sun, 18 Oct 2015 20:00:11 +0200
> Alexis Ballier wrote:
> > On Sun, 18 Oct 2015 13:44:30 +0100
> > Ciaran McCreesh wrote:
> > [...]
> > > > - why should I ever want eapi6 src_prepare instead of
> > > > base_src_prepare ?
> >
On Sun, 18 Oct 2015 20:00:11 +0200
Alexis Ballier wrote:
> On Sun, 18 Oct 2015 13:44:30 +0100
> Ciaran McCreesh wrote:
> [...]
> > > - why should I ever want eapi6 src_prepare instead of
> > > base_src_prepare ?
> >
> > Well base.eclass is supposed to be being removed, and is allegedly
> > b
On Sun, 18 Oct 2015 13:44:30 +0100
Ciaran McCreesh wrote:
[...]
> > - why should I ever want eapi6 src_prepare instead of
> > base_src_prepare ?
>
> Well base.eclass is supposed to be being removed, and is allegedly
> banned for all new ebuilds...
>
> But the big gain for everyone is in repl
On Sun, Oct 18, 2015 at 8:44 AM, Ciaran McCreesh
wrote:
>
> But the big gain for everyone is in replacing a weird, overly clever
> and highly fragile collection of weirdness that's designed to mostly
> accept any dodgy input, with one that just gets you to give it a sane
> input to begin with.
>
On Sun, 18 Oct 2015 10:31:09 +0200
Alexis Ballier wrote:
> > The rationale is that we cannot apply patches in the default
> > src_prepare() unless there is a patch function in the package
> > manager itself. Obviously the default phase cannot call a function
> > from an eclass.
>
> well, that was
On Sun, Oct 18, 2015 at 8:05 AM, hasufell wrote:
>
> If you are messing with the build system in a patch, there is no
> guarantee that eautoreconf will be enough. It might or might not be true
> (see net-irc/hexchat for an example). Are we going to run eautoreconf
> unconditionally then (which is
On 10/18/2015 01:43 PM, Rich Freeman wrote:
> On Sun, Oct 18, 2015 at 7:37 AM, hasufell wrote:
>> On 10/17/2015 08:03 PM, Ciaran McCreesh wrote:
>>> On Sat, 17 Oct 2015 14:49:36 +0200
>>> hasufell wrote:
You can apply the patches post_unpack or post_src_prepare witht hooks.
What's the p
On Sun, 18 Oct 2015 13:54:05 +0200
"Andreas K. Huettel" wrote:
> Am Sonntag, 18. Oktober 2015, 11:23:56 schrieb Alexis Ballier:
>
> >
> > Why not, but when exactly would eapply fail where epatch wouldn't
> > while it should have ?
> >
>
> Different issue but- if your patch only adds a subdi
Am Sonntag, 18. Oktober 2015, 11:23:56 schrieb Alexis Ballier:
>
> Why not, but when exactly would eapply fail where epatch wouldn't
> while it should have ?
>
Different issue but- if your patch only adds a subdirectory, eapply will work
fine while epatch may add the subdir at a random level o
On Sun, Oct 18, 2015 at 7:37 AM, hasufell wrote:
> On 10/17/2015 08:03 PM, Ciaran McCreesh wrote:
>> On Sat, 17 Oct 2015 14:49:36 +0200
>> hasufell wrote:
>>> You can apply the patches post_unpack or post_src_prepare witht hooks.
>>> What's the problem?
>>
>> Running autorecrap.
>>
>
> You can do
On 10/17/2015 08:03 PM, Ciaran McCreesh wrote:
> On Sat, 17 Oct 2015 14:49:36 +0200
> hasufell wrote:
>> You can apply the patches post_unpack or post_src_prepare witht hooks.
>> What's the problem?
>
> Running autorecrap.
>
You can do that with hooks too (which is not very clean tbh). But at
t
On Sun, Oct 18, 2015 at 6:17 AM, Ulrich Mueller wrote:
>> On Sun, 18 Oct 2015, Michał Górny wrote:
>
>> On Sun, 18 Oct 2015 11:54:40 +0200
>> Ulrich Mueller wrote:
>
>>> So the question is if we should add a sentence like the following to
>>> the spec:
>>>
>>> In EAPIs where it is supported,
On Sun, 18 Oct 2015 11:54:40 +0200
Ulrich Mueller wrote:
> > On Sat, 17 Oct 2015, Rich Freeman wrote:
>
> > That would be another reason to have the PM do the check. All it
> > has to do is set an internal flag when it is called, and then check
> > the flag before starting the next phase.
On Sun, 18 Oct 2015 12:07:45 +0200
Michał Górny wrote:
> On Sun, 18 Oct 2015 11:23:56 +0200
> Alexis Ballier wrote:
>
> > > > - what do I, as en ebuild writer, gain from this?
> > >
> > > Reliable patching. Unlike epatch, eapply will not succeed when
> > > the patch unexpectedly applied
On Sun, 18 Oct 2015 12:09:10 +0200
Michał Górny wrote:
> On Sun, 18 Oct 2015 11:34:15 +0200
> Alexis Ballier wrote:
>
> > On Sun, 18 Oct 2015 11:01:27 +0200
> > Michał Górny wrote:
> > [...]
> > > > > It's trivial to change patch to -p1 (I think patchutils can do
> > > > > that).
> >
> On Sun, 18 Oct 2015, Michał Górny wrote:
> On Sun, 18 Oct 2015 11:54:40 +0200
> Ulrich Mueller wrote:
>> So the question is if we should add a sentence like the following to
>> the spec:
>>
>> In EAPIs where it is supported, all ebuilds must run
>> \t{eapply\_user} in the \t{src\_prepare}
On Sun, 18 Oct 2015 11:54:40 +0200
Ulrich Mueller wrote:
> > On Sat, 17 Oct 2015, Rich Freeman wrote:
>
> > That would be another reason to have the PM do the check. All it
> > has to do is set an internal flag when it is called, and then check
> > the flag before starting the next phase.
On Sun, 18 Oct 2015 11:34:15 +0200
Alexis Ballier wrote:
> On Sun, 18 Oct 2015 11:01:27 +0200
> Michał Górny wrote:
> [...]
> > > > It's trivial to change patch to -p1 (I think patchutils can do
> > > > that).
> > >
> > > It is. But the above cases were not whether it is possible, but
> >
On Sun, 18 Oct 2015 11:23:56 +0200
Alexis Ballier wrote:
> > > - what do I, as en ebuild writer, gain from this?
> >
> > Reliable patching. Unlike epatch, eapply will not succeed when
> > the patch unexpectedly applied to the wrong directory.
>
> Why not, but when exactly would eapply fai
On Sun, 18 Oct 2015 11:54:40 +0200
Ulrich Mueller wrote:
> > On Sat, 17 Oct 2015, Rich Freeman wrote:
>
> > That would be another reason to have the PM do the check. All it
> > has to do is set an internal flag when it is called, and then check
> > the flag before starting the next phase.
> On Sat, 17 Oct 2015, Rich Freeman wrote:
> That would be another reason to have the PM do the check. All it
> has to do is set an internal flag when it is called, and then check
> the flag before starting the next phase. Then you can have as many
> levels of conditionals and nested functio
On Sun, 18 Oct 2015 11:01:27 +0200
Michał Górny wrote:
[...]
> > > It's trivial to change patch to -p1 (I think patchutils can do
> > > that).
> >
> > It is. But the above cases were not whether it is possible, but
> > rather desirable.
>
> Consistency is desirable. There is world outside
On Sun, 18 Oct 2015 10:48:47 +0200
Michał Górny wrote:
> On Sun, 18 Oct 2015 10:31:09 +0200
> Alexis Ballier wrote:
>
> > On Sat, 17 Oct 2015 22:47:28 +0200
> > Ulrich Mueller wrote:
> >
> > > > On Sat, 17 Oct 2015, Alexis Ballier wrote:
> > >
> > > > Sorry for coming very la
On Sun, 18 Oct 2015 10:47:01 +0200
Alexis Ballier wrote:
> On Sat, 17 Oct 2015 23:24:47 +0200
> Michał Górny wrote:
>
> > On Sat, 17 Oct 2015 22:08:38 +0200
> > Alexis Ballier wrote:
> >
> > > On Fri, 16 Oct 2015 20:42:20 +0200
> > > Ulrich Mueller wrote:
> > >
> > > > [Resending sinc
On Sun, 18 Oct 2015 10:31:09 +0200
Alexis Ballier wrote:
> On Sat, 17 Oct 2015 22:47:28 +0200
> Ulrich Mueller wrote:
>
> > > On Sat, 17 Oct 2015, Alexis Ballier wrote:
> >
> > > Sorry for coming very late on this, but what is the rationale behind
> > > setting in stone an 'eapply' d
On Sat, 17 Oct 2015 23:24:47 +0200
Michał Górny wrote:
> On Sat, 17 Oct 2015 22:08:38 +0200
> Alexis Ballier wrote:
>
> > On Fri, 16 Oct 2015 20:42:20 +0200
> > Ulrich Mueller wrote:
> >
> > > [Resending since my first message didn't make it to
> > > -dev-announce.]
> > >
> > > The first d
On Sat, 17 Oct 2015 18:16:33 -0400
Rich Freeman wrote:
> On Sat, Oct 17, 2015 at 8:52 AM, Ulrich Mueller
> wrote:
> >
> > That eapply_user is called can be enforced by repoman, or by a QA
> > warning.
> >
>
> I hate to reply again on the same topic, but how would repoman even
> know whether e
On Sat, 17 Oct 2015 22:47:28 +0200
Ulrich Mueller wrote:
> > On Sat, 17 Oct 2015, Alexis Ballier wrote:
>
> > Sorry for coming very late on this, but what is the rationale behind
> > setting in stone an 'eapply' different to an 'epatch' that has been
> > widely tested for decades now ? Or
On Sat, Oct 17, 2015 at 8:52 AM, Ulrich Mueller wrote:
>
> That eapply_user is called can be enforced by repoman, or by a QA
> warning.
>
I hate to reply again on the same topic, but how would repoman even
know whether eapply_user will always get called? Isn't that
equivalent to the halting prob
On Sat, 17 Oct 2015 22:08:38 +0200
Alexis Ballier wrote:
> On Fri, 16 Oct 2015 20:42:20 +0200
> Ulrich Mueller wrote:
>
> > [Resending since my first message didn't make it to -dev-announce.]
> >
> > The first draft of EAPI 6 is ready. I shall post it as a series of
> > 22 patches following th
On Sat, Oct 17, 2015 at 8:51 AM, Michał Górny wrote:
> Dnia 2015-10-17, o godz. 08:38:51
> Rich Freeman napisał(a):
>
>> On Sat, Oct 17, 2015 at 8:25 AM, hasufell wrote:
>> > On 10/17/2015 02:19 PM, Jason A. Donenfeld wrote:
>> >>
>> >> The other question is more critical -- could you merge eapp
On Sat, 17 Oct 2015 14:49:36 +0200
hasufell wrote:
> You can apply the patches post_unpack or post_src_prepare witht hooks.
> What's the problem?
Running autorecrap.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sat, 17 Oct 2015 17:22:10 +0200
hasufell wrote:
> On 10/17/2015 03:07 PM, Ulrich Mueller wrote:
> >> On Sat, 17 Oct 2015, hasufell wrote:
> >
> >> And still doesn't give sufficient control to the user. Documenting
> >> proper hooks is more useful.
> >
> > Nothing prevents the PM f
On Sat, 17 Oct 2015 12:07:03 -0400
"Anthony G. Basile" wrote:
> On 10/17/15 11:00 AM, hasufell wrote:
> > On 10/17/2015 03:47 PM, Alexis Ballier wrote:
> >> On Sat, 17 Oct 2015 14:49:36 +0200
> >> hasufell wrote:
> >>
> >> [...]
> >>> You can apply the patches post_unpack or post_src_prepare
On 10/17/15 11:00 AM, hasufell wrote:
On 10/17/2015 03:47 PM, Alexis Ballier wrote:
On Sat, 17 Oct 2015 14:49:36 +0200
hasufell wrote:
[...]
You can apply the patches post_unpack or post_src_prepare witht hooks.
What's the problem?
autoreconf
Can you elaborate why this would be a problem?
On 10/17/2015 03:07 PM, Ulrich Mueller wrote:
>> On Sat, 17 Oct 2015, hasufell wrote:
>
>> And still doesn't give sufficient control to the user. Documenting
>> proper hooks is more useful.
>
> Nothing prevents the PM from implementing eapply_user() as a hook.
>
Whether that will be the ca
On 10/17/2015 03:47 PM, Alexis Ballier wrote:
> On Sat, 17 Oct 2015 14:49:36 +0200
> hasufell wrote:
>
> [...]
>> You can apply the patches post_unpack or post_src_prepare witht hooks.
>> What's the problem?
>
> autoreconf
>
Can you elaborate why this would be a problem?
On Sat, 17 Oct 2015 14:49:36 +0200
hasufell wrote:
[...]
> You can apply the patches post_unpack or post_src_prepare witht hooks.
> What's the problem?
autoreconf
> On Sat, 17 Oct 2015, hasufell wrote:
> And still doesn't give sufficient control to the user. Documenting
> proper hooks is more useful.
Nothing prevents the PM from implementing eapply_user() as a hook.
Ulrich
pgpvZFlssUzXm.pgp
Description: PGP signature
On 10/17/2015 02:56 PM, Rich Freeman wrote:
> On Sat, Oct 17, 2015 at 8:49 AM, hasufell wrote:
>>
>>> The other feature that is supposed to be in EAPI6 (I didn't read the
>>> draft yet) is that the PM should refuse to install the package if
>>> eapply is never called (ie src_prepare is overridden
On 10/17/2015 02:52 PM, Ulrich Mueller wrote:
>> On Sat, 17 Oct 2015, hasufell wrote:
>
>>> 2. eapply_user really belongs in the PM, especially if it's run by
>>> default. And it needs patch applying function. And if we have to
>>> implement patch applying function anyway, we may as well make
On Sat, Oct 17, 2015 at 8:49 AM, hasufell wrote:
>
>> The other feature that is supposed to be in EAPI6 (I didn't read the
>> draft yet) is that the PM should refuse to install the package if
>> eapply is never called (ie src_prepare is overridden and the ebuild
>> didn't call eapply). It is requ
Dnia 2015-10-17, o godz. 08:38:51
Rich Freeman napisał(a):
> On Sat, Oct 17, 2015 at 8:25 AM, hasufell wrote:
> > On 10/17/2015 02:19 PM, Jason A. Donenfeld wrote:
> >>
> >> The other question is more critical -- could you merge eapply and
> >> eapply_user? Or add some hook to PMS so that eapply
> On Sat, 17 Oct 2015, hasufell wrote:
>> 2. eapply_user really belongs in the PM, especially if it's run by
>> default. And it needs patch applying function. And if we have to
>> implement patch applying function anyway, we may as well make it
>> public to avoid unnecessary duplication.
> U
On 10/17/2015 02:38 PM, Rich Freeman wrote:
> On Sat, Oct 17, 2015 at 8:25 AM, hasufell wrote:
>> On 10/17/2015 02:19 PM, Jason A. Donenfeld wrote:
>>>
>>> The other question is more critical -- could you merge eapply and
>>> eapply_user? Or add some hook to PMS so that eapply_user isn't needed?
>
> On Sat, 17 Oct 2015, Michał Górny wrote:
> Dnia 2015-10-17, o godz. 14:19:15
> "Jason A. Donenfeld" napisał(a):
>> What's the story of eapply? Why does this need to go into the PMS,
>> and not continue to be supplied by epatch from the eclass? What
>> is gained from moving it to PMS, and w
On Sat, Oct 17, 2015 at 8:25 AM, hasufell wrote:
> On 10/17/2015 02:19 PM, Jason A. Donenfeld wrote:
>>
>> The other question is more critical -- could you merge eapply and
>> eapply_user? Or add some hook to PMS so that eapply_user isn't needed?
>> IOW, it'd be nice if every package was, by defau
On 10/17/2015 02:24 PM, Michał Górny wrote:
>
> 2. eapply_user really belongs in the PM, especially if it's run by
> default. And it needs patch applying function. And if we have to
> implement patch applying function anyway, we may as well make it public
> to avoid unnecessary duplication.
>
Un
On 10/17/2015 02:19 PM, Jason A. Donenfeld wrote:
>
> The other question is more critical -- could you merge eapply and
> eapply_user? Or add some hook to PMS so that eapply_user isn't needed?
> IOW, it'd be nice if every package was, by default, patchable by the user.
>
IMO, eapply_user should
Dnia 2015-10-17, o godz. 14:19:15
"Jason A. Donenfeld" napisał(a):
> Hey Ulrich,
>
> I may be a bit late to the discussion, and perhaps I should really just be
> reviewing mailing list posts from years past, but...
>
> What's the story of eapply? Why does this need to go into the PMS, and not
>
78 matches
Mail list logo
