Being able to conveniently patch the programs/libraries is a great feature, but sadly not all ebuild call epatch_user. Please add a call to epatch_user to portage in a way that every ebuild uses it by default. Reproducible: Always
This kind of thing requires EAPI support, since we need to avoid calling the function automatically if the ebuild has already called it. Also, when we call it automatically, we need to handle interactions between patches and autotools files (for example see checksum code for Makefile.am, configure.ac, and configure.in in the autotools-utils_src_prepare function of autotools.eclass).
Another problem is how to put autotools dependencies when needed (and not always, even if it's not a big problem since most people will have them installed always as a ton of packages need them): https://bugs.gentoo.org/show_bug.cgi?id=473230#c1
(In reply to Pacho Ramos from comment #2) > Another problem is how to put autotools dependencies when needed (and not > always, even if it's not a big problem since most people will have them > installed always as a ton of packages need them): > https://bugs.gentoo.org/show_bug.cgi?id=473230#c1 When people use user patches, it is their responsibility to ensure that necessary deps are in place. A similar case happens when the patches themselves add dependencies.
*** Bug 486198 has been marked as a duplicate of this bug. ***
(In reply to Michał Górny from comment #3) > (In reply to Pacho Ramos from comment #2) > > Another problem is how to put autotools dependencies when needed (and not > > always, even if it's not a big problem since most people will have them > > installed always as a ton of packages need them): > > https://bugs.gentoo.org/show_bug.cgi?id=473230#c1 > > When people use user patches, it is their responsibility to ensure that > necessary deps are in place. A similar case happens when the patches > themselves add dependencies. Can't fault either argument. However I have always considered that epatch_user is for patches to a single package, without regard to dependencies or anything else. It's just simply convenient. It is simply a pain to have to copy ebuilds to my local repo and bodge in my patch and digest etc. epatch_user allows easy scraping of patches from bugs.g.o with minimal fuss and makes testing ~arch a little easier - I personally think it should be a feature that is shouted from the rooftops (and supported in all packages) It could be integrated into bugs.g.o in some way so that patches can be delivered to potential testers with easy feedback. You could have patches that are dumped here tagged in some way so that a pseudo overlay (or a real one) introduced them to willing enduser systems and then provide some sort of easy feedback mechanism. Just a thought Jon PS Yes there would be a requirement for a decent disclaimer before allowing people to sign up ...
*** Bug 510244 has been marked as a duplicate of this bug. ***
Removing dependent bugs. This is a bug for a future EAPI feature, not a tracker for ebuilds in the tree. Please open a separate tracker if you think that one is necessary.
(In reply to Ulrich Müller from comment #7) > Removing dependent bugs. This is a bug for a future EAPI feature, not a > tracker for ebuilds in the tree. I was trying to manage many bugs. Sorry for the confusion this apparently caused you. > Please open a separate tracker if you think that one is necessary. No.
--- /usr/lib/portage/bin/phase-functions.sh +++ /usr/lib/portage/bin/phase-functions.sh @@ -379,6 +379,8 @@ __vecho ">>> Source prepared." __ebuild_phase post_src_prepare + [[ -e "${T}/epatch_user.log" ]] || die "epatch_user not called" + trap - SIGINT SIGQUIT } Anything less severe will not work.
(In reply to Hristo Venev from comment #9) Breaking the tree for all users? Nope.
I see it as motivation for developers to unbreak their ebuilds.
(In reply to Hristo Venev from comment #11) > I see it as motivation for developers to unbreak their ebuilds. The spec does not require epatch_user to be called (nor does it know anything about epatch), and so it is not a breakage not to do so.
Actually, we have a roadmap, namely adding an "eapply" function to the PM in the next EAPI (bug 463768) and to call it for user patches (this bug). It doesn't involve imposing breakage on users for a large fraction of ebuilds. Restricting this bug to developers now.
Well, to be honest, it is possible to force such a thing in EAPI=6 -- therefore avoiding breakage in existing ebuilds. But I don't think it's a good idea, especially with a particular number of developers being against epatch_user. As I see it, forcing it on everyone will result in developers delaying the switch to EAPI=6 and trying to workaround the feature. Last thing we need right now is more developer issues.
There's always the option of releasing EAPI="6-unstrict" and EAPI="6" simultaneously, where the former just introduces new features. It's icky, of course, but it might be the least painful option.
Well, the Council agreed on the 'by default' variant rather than 'always', so let's correct the bug title.
*** Bug 460228 has been marked as a duplicate of this bug. ***
(In reply to Michał Górny from comment #17) > Well, the Council agreed on the 'by default' variant rather than 'always', > so let's correct the bug title. Apply user patch(es) depending on new special global USE (user_patch)? Maybe even exiting with error if this USE is on, but no patches present. Looks nicely. Short summary of bug #460228: Keeping in mind reply on comment #17, suggested USE flag 'user_patch' visualises packages to be patched by user patches with existing portage's mechanisms. But in metadata (primarily for eix, keeping in mind it's very incomplete USE flag support) I find useful to add a special suffix to mark user-patched packages. Recent format: PVR Contains the version number with the revision. xfree-4.2.1-r2.ebuild --> $PVR=='4.2.1-r2' May be extended to something like: PVR Contains the version number with the revision. xfree-4.2.1-r2.ebuild --> $PVR=='4.2.1-r2p1' (built with applying one user patch)
(In reply to Sergey S. Starikoff from comment #19) > Apply user patch(es) depending on new special global USE (user_patch)? Maybe > even exiting with error if this USE is on, but no patches present. We simply apply patches if the user has placed them into the appropriate directory. Why would we to control it with an additional USE flag? > May be extended to something like: > PVR Contains the version number with the revision. > xfree-4.2.1-r2.ebuild --> $PVR=='4.2.1-r2p1' Not going to happen.
(In reply to Ulrich Müller from comment #20) > > Apply user patch(es) depending on new special global USE (user_patch)? Maybe > > even exiting with error if this USE is on, but no patches present. > > We simply apply patches if the user has placed them into the appropriate > directory. Why would we to control it with an additional USE flag? I know it and use this feature. It may be useful to rebuild package with/without applying patch without changes in system configs, that may be useful for test purposes. But I've suggested it keeping in mind first of all an indicator of availability user patch feature for ebuild, without opening it in editor and reading eclass' manual pages. Just this week I've needed to add a custom (user) patch to package, which don't support user patch feature. > > May be extended to something like: > > PVR Contains the version number with the revision. > > xfree-4.2.1-r2.ebuild --> $PVR=='4.2.1-r2p1' > > Not going to happen. I also don't see a way to solve this issue. But missing difference between ordinar and user_patched packages should move issue to debug process.
(In reply to theodor from comment #0) > but sadly not all ebuild call epatch_user. Please add a call to epatch_user to > portage in a way that every ebuild uses it by default. You could be suprised, but user_patch is not the only way of applying custom patches. You could do the same using feature per-package bashrc file. For example to apply a patch to x11-libs/vte you should: 1. Create file /etc/portage/env/x11-libs/vte pre_src_prepare () { EPATCH_SOURCE="/etc/portage/patches.rc/$CATEGORY/$PN/" \ EPATCH_SUFFIX="patch" \ EPATCH_FORCE="yes" epatch } 2. Create patch dir /etc/portage/patches/$CATEGORY/$PN/, i.e.: mkdir /etc/portage/patches.rc/x11-libs/vte 3. Place into it '.patch' suffixed patch file(s) 4. Rebuild target package and check. Patche(s) will be applied even if ebuild don't support user patch feature.
*** Bug 553770 has been marked as a duplicate of this bug. ***
*** Bug 557214 has been marked as a duplicate of this bug. ***
In EAPI 6: https://gitweb.gentoo.org/proj/pms.git/commit/?id=aa7ce7631a20c0a1369c32f8e207f4fb40edb33c https://gitweb.gentoo.org/proj/pms.git/commit/?id=0d2ad45e5083cea349f4c4e4a596e6b03396f24b https://gitweb.gentoo.org/proj/pms.git/commit/?id=c399c49b71762ed969e29146f5f85d071905296d