Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 475288 - [Future EAPI] Support applying user patches
Summary: [Future EAPI] Support applying user patches
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal enhancement with 1 vote (vote)
Assignee: PMS/EAPI
URL:
Whiteboard: in-eapi-6
Keywords:
: 460228 486198 510244 553770 557214 (view as bug list)
Depends on: 463768
Blocks: future-eapi
  Show dependency tree
 
Reported: 2013-06-30 08:12 UTC by theodor
Modified: 2015-11-08 21:48 UTC (History)
10 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description theodor 2013-06-30 08:12:35 UTC
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
Comment 1 Zac Medico gentoo-dev 2013-06-30 13:04:31 UTC
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).
Comment 2 Pacho Ramos gentoo-dev 2013-06-30 13:21:52 UTC
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
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-06-30 14:29:42 UTC
(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.
Comment 4 SpanKY gentoo-dev 2013-12-17 23:37:14 UTC
*** Bug 486198 has been marked as a duplicate of this bug. ***
Comment 5 Jon Gerdes 2014-04-07 00:54:06 UTC
(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 ...
Comment 6 Jeroen Roovers (RETIRED) gentoo-dev 2014-05-24 19:47:32 UTC
*** Bug 510244 has been marked as a duplicate of this bug. ***
Comment 7 Ulrich Müller gentoo-dev 2014-05-24 20:14:10 UTC
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.
Comment 8 Jeroen Roovers (RETIRED) gentoo-dev 2014-05-24 20:17:40 UTC
(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.
Comment 9 Hristo Venev 2014-05-25 16:32:23 UTC
--- /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.
Comment 10 Ulrich Müller gentoo-dev 2014-05-25 17:09:16 UTC
(In reply to Hristo Venev from comment #9)

Breaking the tree for all users? Nope.
Comment 11 Hristo Venev 2014-05-25 17:15:03 UTC
I see it as motivation for developers to unbreak their ebuilds.
Comment 12 Ciaran McCreesh 2014-05-25 17:23:39 UTC
(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.
Comment 13 Ulrich Müller gentoo-dev 2014-05-25 17:31:54 UTC
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.
Comment 14 Ulrich Müller gentoo-dev 2014-05-25 17:34:42 UTC
(In reply to Hristo Venev from comment #9)

Breaking the tree for all users? Nope.
Comment 15 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-05-25 17:41:16 UTC
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.
Comment 16 Ciaran McCreesh 2014-05-25 17:47:47 UTC
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.
Comment 17 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-09-06 22:28:49 UTC
Well, the Council agreed on the 'by default' variant rather than 'always', so let's correct the bug title.
Comment 18 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-09-06 22:29:40 UTC
*** Bug 460228 has been marked as a duplicate of this bug. ***
Comment 19 Sergey S. Starikoff 2014-09-11 07:47:19 UTC
(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)
Comment 20 Ulrich Müller gentoo-dev 2014-09-11 15:08:14 UTC
(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.
Comment 21 Sergey S. Starikoff 2014-09-12 09:43:42 UTC
(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.
Comment 22 Sergey S. Starikoff 2014-09-12 09:52:58 UTC
(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.
Comment 23 Zac Medico gentoo-dev 2015-07-02 17:27:42 UTC
*** Bug 553770 has been marked as a duplicate of this bug. ***
Comment 24 Brian Evans (RETIRED) gentoo-dev 2015-08-10 12:44:43 UTC
*** Bug 557214 has been marked as a duplicate of this bug. ***