Re: [gentoo-dev] [RFC] [epatch_user] Proposal: add possibility to tolerable-fail for some patches (plus add groupping support)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/06/14 05:42 AM, Michał Górny wrote: > Dnia 2014-06-15, o godz. 16:06:57 "Vadim A. Misbakh-Soloviov" > napisał(a): > >> My idea is to allow failing for some patches without breaking >> build at all. And, in parallel, to add groupping. >> >> How I imagine that: >> >> etc/portage/patches/app-cat// | | - group_name/ | | | >> |- 01_foo.patch | |- 02_bar.patch | |- <...> | |- >> 01_moo.patch |- 99_meow.patch >> >> Where every first-level piece (patch or group) in >> ```etc/portage/patches/app-cat//``` MAY tolerably fail (not >> causing "die" for emerge), but if one of the patches inside the >> group fails, then group MUST NOT be applied at all (and all >> previously applied patches from this group MUST be reversed). > > Just don't. > > Or more specifically: it's not worth the effort, the extra > complexity, the confusion and the wholesale mess involved. > Agreed. patches, or groups thereof, should not ever be fail'able without also stopping the emerge process. And the whole if-one-fails-then-revert-the-group thing would be hell to implement. Even if the patch fails because it's determined to have been "already applied", there's no guarantee that this check is accurate (ie what upstream applied is the same as your patch). Best to just fail, to let users know they need to clean up their patches. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlOfB5kACgkQ2ugaI38ACPDDRgEAujxxI9LLTs8Bj+nNgGgUcG15 XLNXD3vtpzbVmtE6MsgBAKAGO4Ysjwt07uVMlXWNqQz31QRUza24/lIOkVafnTDd =5G8J -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] [epatch_user] Proposal: add possibility to tolerable-fail for some patches (plus add groupping support)
Am Sonntag, 15. Juni 2014, 11:06:57 schrieb Vadim A. Misbakh-Soloviov: > My idea is to allow failing for some patches without breaking build at all. Please No. It just generates a big mess. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] [epatch_user] Proposal: add possibility to tolerable-fail for some patches (plus add groupping support)
On Sun, 15 Jun 2014 16:06:57 +0700 "Vadim A. Misbakh-Soloviov" wrote: > My idea is to allow failing for some patches without breaking build > at all. And, in parallel, to add groupping. > > [...] > > Any objections/approvals/suggestions? What are the use cases of this idea? What is its goal? In my use case, I've found or written patches with a permanent purpose; therefore, I'd like the patches to apply or die hard with a purpose. I can't imagine an use case where you don't want them to apply. Temporary backported patches (eg. from version 2) come to mind; it then becomes tricky to know whether it fails because it is the new version (2), or whether it is a version (<2) in between that breaks. That would become a whole new feature request with specific directory, file or header syntaxes, which takes time to implement; at which point, one wonders if just (re)moving away the patch when you see it fail in the early src_prepare phase followed by a --resume is more favorable. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] [epatch_user] Proposal: add possibility to tolerable-fail for some patches (plus add groupping support)
Vadim A. Misbakh-Soloviov: > My idea is to allow failing for some patches without breaking build at all. > And, in parallel, to > add groupping. > > How I imagine that: > > etc/portage/patches/app-cat// > | > | - group_name/ > | | > | |- 01_foo.patch > | |- 02_bar.patch > | |- <...> > | > |- 01_moo.patch > |- 99_meow.patch > > Where every first-level piece (patch or group) in > ```etc/portage/patches/app-cat//``` MAY > tolerably fail (not causing "die" for emerge), but if one of the patches > inside the group fails, then > group MUST NOT be applied at all (and all previously applied patches from > this group MUST be > reversed). > > > Any objections/approvals/suggestions? > > > How does epatch know if I want a patch to cause "|| die" or not? The only use case I see here is "don't want to clean up old patches".
Re: [gentoo-dev] [RFC] [epatch_user] Proposal: add possibility to tolerable-fail for some patches (plus add groupping support)
Dnia 2014-06-15, o godz. 16:06:57 "Vadim A. Misbakh-Soloviov" napisał(a): > My idea is to allow failing for some patches without breaking build at all. > And, in parallel, to > add groupping. > > How I imagine that: > > etc/portage/patches/app-cat// > | > | - group_name/ > | | > | |- 01_foo.patch > | |- 02_bar.patch > | |- <...> > | > |- 01_moo.patch > |- 99_meow.patch > > Where every first-level piece (patch or group) in > ```etc/portage/patches/app-cat//``` MAY > tolerably fail (not causing "die" for emerge), but if one of the patches > inside the group fails, then > group MUST NOT be applied at all (and all previously applied patches from > this group MUST be > reversed). Just don't. Or more specifically: it's not worth the effort, the extra complexity, the confusion and the wholesale mess involved. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] [RFC] [epatch_user] Proposal: add possibility to tolerable-fail for some patches (plus add groupping support)
My idea is to allow failing for some patches without breaking build at all. And, in parallel, to add groupping. How I imagine that: etc/portage/patches/app-cat// | | - group_name/ | | | |- 01_foo.patch | |- 02_bar.patch | |- <...> | |- 01_moo.patch |- 99_meow.patch Where every first-level piece (patch or group) in ```etc/portage/patches/app-cat//``` MAY tolerably fail (not causing "die" for emerge), but if one of the patches inside the group fails, then group MUST NOT be applied at all (and all previously applied patches from this group MUST be reversed). Any objections/approvals/suggestions? signature.asc Description: This is a digitally signed message part.