Mailing List Archive

Proposed change to base.eclass: patch || die
Hi all,

base.eclass (which inherited by many other eclasses) has an src_unpack
supporting patching from patchfiles listed in $PATCHES. However, today, if
patching fails the process doesn't abort. So I propose:

==================
--- base.eclass 11 Jul 2005 15:08:06 -0000 1.27
+++ base.eclass 29 Jul 2005 13:45:39 -0000
@@ -35,11 +35,11 @@ base_src_unpack() {
cd ${S}
for x in $PATCHES; do
debug-print "$FUNCNAME: autopatch: patching
from ${x}"
- patch -p0 < ${x}
+ patch -p0 < ${x} || die "Patchfile $x failed
to apply"
done
for x in $PATCHES1; do
debug-print "$FUNCNAME: autopatch: patching
-p1 from ${x}"
- patch -p1 < ${x}
+ patch -p1 < ${x} || die "Patchfile $x failed
to apply"
done
;;
all)
====================

This will make some ebuilds fail which accidentally rely on non-applying
patches, which is the correct thing to do IMHO. Objections?

--
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
Re: Proposed change to base.eclass: patch || die [ In reply to ]
On Friday 29 July 2005 15:56, Dan Armak wrote:
> base.eclass (which inherited by many other eclasses) has an src_unpack
> supporting patching from patchfiles listed in $PATCHES. However, today, if
> patching fails the process doesn't abort.
Why can't we just use epatch?

--
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)
Re: Proposed change to base.eclass: patch || die [ In reply to ]
On Friday 29 July 2005 16:57, Diego 'Flameeyes' Pettenò wrote:
> On Friday 29 July 2005 15:56, Dan Armak wrote:
> > base.eclass (which inherited by many other eclasses) has an src_unpack
> > supporting patching from patchfiles listed in $PATCHES. However, today,
> > if patching fails the process doesn't abort.
>
> Why can't we just use epatch?
We can. It's just that base.eclass existed long before epatch, so it doesn't
use it :-)

Anyway, the effective change would be to die if patching fails (and support
patchlevels != 0), so my orig question stands.

--
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
Re: Proposed change to base.eclass: patch || die [ In reply to ]
On Friday 29 July 2005 16:05, Dan Armak wrote:
> Anyway, the effective change would be to die if patching fails (and support
> patchlevels != 0), so my orig question stands.
epatch already takes care of failing, that's why I was thinking about that :)

--
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)
Re: Re: Proposed change to base.eclass: patch || die [ In reply to ]
On Friday 29 July 2005 17:58, Duncan wrote:
> Diego 'Flameeyes' Pettenò posted
> <200507291611.47342@enterprise.flameeyes.is-a-geek.org>, excerpted below,
>
> on Fri, 29 Jul 2005 16:11:46 +0200:
> > On Friday 29 July 2005 16:05, Dan Armak wrote:
> >> Anyway, the effective change would be to die if patching fails (and
> >> support patchlevels != 0), so my orig question stands.
> >
> > epatch already takes care of failing, that's why I was thinking about
> > that
> >
> > :)
>
> More on the point... what about replacing the current base.eclass code
> with appropriate calls to epatch? This would mean changes/fixes to epatch
> would automatically propagate, while continuing to maintain compatibility
> by keeping the base.eclass functionality around.
Well as I wrote in my previous reply, I see no objection. I wanted to make
sure this is OK with all base.eclass users, beyond kde.eclass.

--
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
Re: Re: Proposed change to base.eclass: patch || die [ In reply to ]
On Friday 29 July 2005 11:14 am, Dan Armak wrote:
> On Friday 29 July 2005 17:58, Duncan wrote:
> > Diego 'Flameeyes' Pettenò posted
> > <200507291611.47342@enterprise.flameeyes.is-a-geek.org>, excerpted below,
> >
> > on Fri, 29 Jul 2005 16:11:46 +0200:
> > > On Friday 29 July 2005 16:05, Dan Armak wrote:
> > >> Anyway, the effective change would be to die if patching fails (and
> > >> support patchlevels != 0), so my orig question stands.
> > >
> > > epatch already takes care of failing, that's why I was thinking about
> > > that
> > >
> > > :)
> >
> > More on the point... what about replacing the current base.eclass code
> > with appropriate calls to epatch? This would mean changes/fixes to
> > epatch would automatically propagate, while continuing to maintain
> > compatibility by keeping the base.eclass functionality around.
>
> Well as I wrote in my previous reply, I see no objection. I wanted to make
> sure this is OK with all base.eclass users, beyond kde.eclass.

from a QA point of view, no package should apply a patch, have the patching
fail, but continue to emerge ... who knows what kind of garbage you'll end up
with
-mike

--
gentoo-dev@gentoo.org mailing list
Re: Re: Proposed change to base.eclass: patch || die [ In reply to ]
On Friday 29 July 2005 17:31, Mike Frysinger wrote:
> from a QA point of view, no package should apply a patch, have the patching
> fail, but continue to emerge ... who knows what kind of garbage you'll end
> up with
This can be read as "it's good to use epatch" ? :P

--
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)
Re: Re: Proposed change to base.eclass: patch || die [ In reply to ]
On Friday 29 July 2005 17:40, Diego 'Flameeyes' Pettenò wrote:
> This can be read as "it's good to use epatch" ? :P

It's just less text to write PATCHES="foo ...", if you don't have a src_unpack
function in the particular ebuild.


Carsten
Re: Re: Proposed change to base.eclass: patch || die [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Carsten Lohrke wrote:
| On Friday 29 July 2005 17:40, Diego 'Flameeyes' Pettenò wrote:
|
|>This can be read as "it's good to use epatch" ? :P
|
|
| It's just less text to write PATCHES="foo ...", if you don't have a
src_unpack
| function in the particular ebuild.

That doesn't really make any sense. You could just as easily use PATCHES
if you ran s/patch -p0 </epatch/.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC6lvGXVaO67S1rtsRAlsiAKDKwmY+Bhnyev3/nFPUVMjswn7nowCgvqoS
9cycCCpng0ZFDqioTkhkw1g=
=vHNY
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list
Re: Re: Proposed change to base.eclass: patch || die [ In reply to ]
On Friday 29 July 2005 18:39, Donnie Berkholz wrote:
> That doesn't really make any sense. You could just as easily use PATCHES
> if you ran s/patch -p0 </epatch/.

Don't get what you want to say... I read Diego's comment as an ironic one,
that there's no need for the PATCHES variable, which is of course true, but
you don't have to write "src_unpack(){ foo_unpack ; epatch some_patch }" just
for a single patch. I'm a bit surprised by such a comment on this triviality.


carsten
Re: Re: Proposed change to base.eclass: patch || die [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Carsten Lohrke wrote:
| On Friday 29 July 2005 18:39, Donnie Berkholz wrote:
|
|>That doesn't really make any sense. You could just as easily use PATCHES
|>if you ran s/patch -p0 </epatch/.
|
|
| Don't get what you want to say... I read Diego's comment as an ironic
one,
| that there's no need for the PATCHES variable, which is of course
true, but
| you don't have to write "src_unpack(){ foo_unpack ; epatch some_patch
}" just
| for a single patch. I'm a bit surprised by such a comment on this
triviality.

I just don't see how his comment had anything to do with PATCHES. It was
simply replacing a direct call to patch with epatch. Thus, your comment
doesn't make any sense to me, either.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC6mKyXVaO67S1rtsRAgE5AJ9uuuMqXeF1vgZQINLCiQD0F61//gCfdO3F
UZPy3sZiCl9TMP2Bh3WRkmI=
=Iu2D
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list
Re: Re: Proposed change to base.eclass: patch || die [ In reply to ]
On Friday 29 July 2005 19:02, Carsten Lohrke wrote:
> Don't get what you want to say... I read Diego's comment as an ironic one,
> that there's no need for the PATCHES variable, which is of course true, but
> you don't have to write "src_unpack(){ foo_unpack ; epatch some_patch }"
> just for a single patch. I'm a bit surprised by such a comment on this
> triviality.
No I wasn't saying that it's useless to use PATCHES.. actually, if this is
going to be fixed (the failure stuff) I think I'll start using it more.
What I was saying was that Mike's comment could have been read as "just move
to epatch, if something breaks (like packages dying as the patch fails to
apply) it was broken QA-wise before.

No irony, really.

--
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)
Re: Re: Proposed change to base.eclass: patch || die [ In reply to ]
On Friday 29 July 2005 19:09, Donnie Berkholz wrote:
> I just don't see how his comment had anything to do with PATCHES.

Gasp - communication is not error free. News to you!? I mistook him, that's
all.

> Thus, your comment doesn't make any sense to me, either.

In my context it does, unfortunately it neither matches yours nor Diego's.


Carsten
Re: Proposed change to base.eclass: patch || die [ In reply to ]
On Friday 29 July 2005 15:56, Dan Armak wrote:
> base.eclass (which inherited by many other eclasses) has an src_unpack
> supporting patching from patchfiles listed in $PATCHES. However, today, if
> patching fails the process doesn't abort.
About this, there are still problems about committing a change on base.eclass
to use epatch instead of patch? (so that it also takes care of recognize the
right strip option)

--
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)
Re: Proposed change to base.eclass: patch || die [ In reply to ]
On Friday 05 August 2005 12:34, Diego 'Flameeyes' Pettenò wrote:
> On Friday 29 July 2005 15:56, Dan Armak wrote:
> > base.eclass (which inherited by many other eclasses) has an src_unpack
> > supporting patching from patchfiles listed in $PATCHES. However, today,
> > if patching fails the process doesn't abort.
>
> About this, there are still problems about committing a change on
> base.eclass to use epatch instead of patch? (so that it also takes care of
> recognize the right strip option)
I don't think there are any problems.

I've been using a modified base.eclass that died if patching failed for the
last few weeks, so I know the packages I have installed don't have failing
patches. Since this thread started I've modified it to use epatch and so far
that's worked OK.

So I think we can commit this (with epatch, that is). Can I consider the
thread so far a consensus to let me do it?

BTW, I've managed to lost all my mail from Thursday, so if there was something
relevant in this thread could someone please forward it to me.

--
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
Re: Proposed change to base.eclass: patch || die [ In reply to ]
Diego 'Flameeyes' Pettenò posted
<200507291611.47342@enterprise.flameeyes.is-a-geek.org>, excerpted below,
on Fri, 29 Jul 2005 16:11:46 +0200:

> On Friday 29 July 2005 16:05, Dan Armak wrote:
>> Anyway, the effective change would be to die if patching fails (and
>> support patchlevels != 0), so my orig question stands.
> epatch already takes care of failing, that's why I was thinking about that
> :)

More on the point... what about replacing the current base.eclass code
with appropriate calls to epatch? This would mean changes/fixes to epatch
would automatically propagate, while continuing to maintain compatibility
by keeping the base.eclass functionality around.

--
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list