[gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user
This is particularly useful for people who run alternative
package managers and want to control their configuration.
Github-PR: https://github.com/gentoo/gentoo/pull/69
---
eclass/eutils.eclass | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index fecd375..be65960 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -350,6 +350,12 @@ EPATCH_FORCE="no"
# List of patches not to apply. Note this is only file names,
# and not the full path. Globs accepted.
+# @VARIABLE: EPATCH_USER_SOURCE
+# @DESCRIPTION:
+# Location for user patches, see the epatch_user function.
+# Should be set by the user. Don't set this in ebuilds.
+: ${EPATCH_USER_SOURCE:=${PORTAGE_CONFIGROOT%/}/etc/portage/patches}
+
# @FUNCTION: epatch
# @USAGE: [options] [patches] [dirs of patches]
# @DESCRIPTION:
@@ -697,11 +703,11 @@ epatch_user() {
[[ -e ${applied} ]] && return 2
# don't clobber any EPATCH vars that the parent might want
- local EPATCH_SOURCE check
base=${PORTAGE_CONFIGROOT%/}/etc/portage/patches
+ local EPATCH_SOURCE check
for check in ${CATEGORY}/{${P}-${PR},${P},${PN}}{,:${SLOT}}; do
- EPATCH_SOURCE=${base}/${CTARGET}/${check}
- [[ -r ${EPATCH_SOURCE} ]] ||
EPATCH_SOURCE=${base}/${CHOST}/${check}
- [[ -r ${EPATCH_SOURCE} ]] || EPATCH_SOURCE=${base}/${check}
+ EPATCH_SOURCE=${EPATCH_USER_SOURCE}/${CTARGET}/${check}
+ [[ -r ${EPATCH_SOURCE} ]] ||
EPATCH_SOURCE=${EPATCH_USER_SOURCE}/${CHOST}/${check}
+ [[ -r ${EPATCH_SOURCE} ]] ||
EPATCH_SOURCE=${EPATCH_USER_SOURCE}/${check}
if [[ -d ${EPATCH_SOURCE} ]] ; then
EPATCH_SOURCE=${EPATCH_SOURCE} \
EPATCH_SUFFIX="patch" \
--
2.5.1
Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user
On Sat, Sep 5, 2015 at 6:46 AM, Julian Ospald wrote: > This is particularly useful for people who run alternative > package managers and want to control their configuration. I certainly support the principle, but for the sake of transparency can we try to coordinate this so that the setting name doesn't change when this moves into the package manager for EAPI6? PMS is more about the content of the ebuilds, so presumably all package managers could structure how patches are provided by the user in whatefver way is most consistent with how they already operate. -- Rich
Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user
On 09/05/2015 02:07 PM, Rich Freeman wrote: > On Sat, Sep 5, 2015 at 6:46 AM, Julian Ospald wrote: >> This is particularly useful for people who run alternative >> package managers and want to control their configuration. > > I certainly support the principle, but for the sake of transparency > can we try to coordinate this so that the setting name doesn't change > when this moves into the package manager for EAPI6? PMS is more about > the content of the ebuilds, so presumably all package managers could > structure how patches are provided by the user in whatefver way is > most consistent with how they already operate. > Of course, PMS should not refer to directories like "/etc/portage", but I am not sure it's the place to introduce variables for users to configure their PM behavior. I'd rather expect this to be PM-specific. At that point, probably nothing will change for portage users anyway. Everything else is not within our control.
Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user
> On Sat, 5 Sep 2015, Rich Freeman wrote: > I certainly support the principle, but for the sake of transparency > can we try to coordinate this so that the setting name doesn't > change when this moves into the package manager for EAPI6? So far, the EAPI 6 draft says [1]: eapply_user Takes no arguments. Package managers supporting it apply user-provided patches to the source tree in the current working directory. Exact behaviour is implementation defined and beyond the scope of this specification. Package managers not supporting it must implement the function as a no-op. Only available in EAPIs listed in table [...] as supporting eapply_user. > PMS is more about the content of the ebuilds, so presumably all > package managers could structure how patches are provided by the > user in whatefver way is most consistent with how they already > operate. Exactly, IMHO we should leave the details how this is implemented to the package manager (including the option not to implement it). This is of course open for discussion. Ulrich [1] https://gitweb.gentoo.org/proj/pms.git/diff/pkg-mgr-commands.tex?h=eapi-6&id=c82042d29a03defbb639050e5b3d265f74cbbee6 pgpvhuGFBKwym.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user
On 09/05/2015 02:42 PM, Ulrich Mueller wrote: >> On Sat, 5 Sep 2015, Rich Freeman wrote: > >> I certainly support the principle, but for the sake of transparency >> can we try to coordinate this so that the setting name doesn't >> change when this moves into the package manager for EAPI6? > > So far, the EAPI 6 draft says [1]: > >eapply_user >Takes no arguments. Package managers supporting it apply >user-provided patches to the source tree in the current working >directory. Exact behaviour is implementation defined and beyond >the scope of this specification. Package managers not supporting >it must implement the function as a no-op. Only available in >EAPIs listed in table [...] as supporting eapply_user. > >> PMS is more about the content of the ebuilds, so presumably all >> package managers could structure how patches are provided by the >> user in whatefver way is most consistent with how they already >> operate. > > Exactly, IMHO we should leave the details how this is implemented > to the package manager (including the option not to implement it). > This is of course open for discussion. > Right, I don't even see a reason to make the patch location configurable once it is implemented in package managers. This is really just about eutils.eclass.
Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user
On Sat, Sep 5, 2015 at 8:46 AM, hasufell wrote: > On 09/05/2015 02:42 PM, Ulrich Mueller wrote: >>> On Sat, 5 Sep 2015, Rich Freeman wrote: >> >>> I certainly support the principle, but for the sake of transparency >>> can we try to coordinate this so that the setting name doesn't >>> change when this moves into the package manager for EAPI6? >> >> So far, the EAPI 6 draft says [1]: >> >>eapply_user >>Takes no arguments. Package managers supporting it apply >>user-provided patches to the source tree in the current working >>directory. Exact behaviour is implementation defined and beyond >>the scope of this specification. Package managers not supporting >>it must implement the function as a no-op. Only available in >>EAPIs listed in table [...] as supporting eapply_user. >> >>> PMS is more about the content of the ebuilds, so presumably all >>> package managers could structure how patches are provided by the >>> user in whatefver way is most consistent with how they already >>> operate. >> >> Exactly, IMHO we should leave the details how this is implemented >> to the package manager (including the option not to implement it). >> This is of course open for discussion. >> > > Right, I don't even see a reason to make the patch location configurable > once it is implemented in package managers. > > This is really just about eutils.eclass. > I wasn't suggesting that the configuration of the path be made a part of PMS. I was suggesting that somebody talk to the portage developers about how they intend to implement EAPI6 so that users don't have to go into their make.conf and change EPATCH_USER_SOURCE to EAPPY_USER_SOURCE or something silly like that, or more likely define both since pre-6 ebuilds will use one setting and post-6 ebuilds will use the other. I do realize that there is no technical constraint that forces us to be nice to our users. It's just good manners. :) (And I do realize that portage isn't the only package manager out there. By all means try to do this in a way that is easiest on users of all of them.) -- Rich
Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user
On Sat, Sep 05, 2015 at 02:42:15PM +0200, Ulrich Mueller wrote: > > On Sat, 5 Sep 2015, Rich Freeman wrote: > > > I certainly support the principle, but for the sake of transparency > > can we try to coordinate this so that the setting name doesn't > > change when this moves into the package manager for EAPI6? > > So far, the EAPI 6 draft says [1]: > >eapply_user >Takes no arguments. Package managers supporting it apply >user-provided patches to the source tree in the current working >directory. Exact behaviour is implementation defined and beyond >the scope of this specification. Package managers not supporting >it must implement the function as a no-op. Only available in >EAPIs listed in table [...] as supporting eapply_user. Is there a reason to pick eapply_user rather than epatch_user? I think the second one would fit better with what we already have. Alternatively, if we would like to avoid adding a new function, it could be something like epatch --user or epatch -d $DIRECTORY_WITH_PATCHES, where $DIRECTORY_WITH_PATCHES either defaults to something like $EPATCH_SOURCE_USER, or can be specified via package.env. This takes the burden away from the package manager for where to put patches, and lets the user make that choice. Cheers, —Guilherme
Re: [gentoo-dev] [PATCH] eutils.eclass: Allow to configure base patch location for epatch_user
On 09/05/2015 06:14 PM, Guilherme Amadio wrote: > On Sat, Sep 05, 2015 at 02:42:15PM +0200, Ulrich Mueller wrote: >>> On Sat, 5 Sep 2015, Rich Freeman wrote: >> >>> I certainly support the principle, but for the sake of transparency >>> can we try to coordinate this so that the setting name doesn't >>> change when this moves into the package manager for EAPI6? >> >> So far, the EAPI 6 draft says [1]: >> >>eapply_user >>Takes no arguments. Package managers supporting it apply >>user-provided patches to the source tree in the current working >>directory. Exact behaviour is implementation defined and beyond >>the scope of this specification. Package managers not supporting >>it must implement the function as a no-op. Only available in >>EAPIs listed in table [...] as supporting eapply_user. > > Is there a reason to pick eapply_user rather than epatch_user? I think > the second one would fit better with what we already have. > Alternatively, if we would like to avoid adding a new function, it could > be something like epatch --user or epatch -d $DIRECTORY_WITH_PATCHES, > where $DIRECTORY_WITH_PATCHES either defaults to something like > $EPATCH_SOURCE_USER, or can be specified via package.env. This takes the > burden away from the package manager for where to put patches, and lets > the user make that choice. > Please start a new thread for discussing EAPI-6 features. This is offtopic here.
[gentoo-dev] [RFC] dev-rust category
Hi, I have plans to split ?/cargo-bin [1] package from the dev-lang/rust-bin one. We have already dev-rust/cargo package in the rust overlay[2]. It would be logical to have dev-rust/cargo-bin package then. But there is a problem: it will be the only package in this category in the tree and it is not welcome to have categories with small number of packages. Other rust stuff will appear, but later (with no estimate), as a number of problems with packaging source rust packages should be solved before (afaik upstream also has plans to improve rust packaging). The same about moving source cargo to the tree. So what is better, create dev-util/cargo-bin package and later, when rust infrastructure grows, move it to the dev-rust category or create new category now? [1] https://crates.io/ [2] https://github.com/Heather/gentoo-rust -- Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] dev-rust category
On 09/05/2015 02:21 PM, Jauhien Piatlicki wrote: > Hi, > > I have plans to split ?/cargo-bin [1] package from the dev-lang/rust-bin > one. We have already dev-rust/cargo package in the rust overlay[2]. > > It would be logical to have dev-rust/cargo-bin package then. But there > is a problem: it will be the only package in this category in the tree > and it is not welcome to have categories with small number of packages. > Other rust stuff will appear, but later (with no estimate), as a number > of problems with packaging source rust packages should be solved before > (afaik upstream also has plans to improve rust packaging). The same > about moving source cargo to the tree. > > So what is better, create dev-util/cargo-bin package and later, when > rust infrastructure grows, move it to the dev-rust category or create > new category now? > > [1] https://crates.io/ > [2] https://github.com/Heather/gentoo-rust > > -- > Jauhien > I think cargo should probably go in dev-util with other rust libraries and programs going into dev-rust as needed, but that's just me :D -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] dev-rust category
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/05/2015 01:04 PM, Matthew Thode wrote: > On 09/05/2015 02:21 PM, Jauhien Piatlicki wrote: >> Hi, >> >> I have plans to split ?/cargo-bin [1] package from the >> dev-lang/rust-bin one. We have already dev-rust/cargo package in >> the rust overlay[2]. >> >> It would be logical to have dev-rust/cargo-bin package then. But >> there is a problem: it will be the only package in this category >> in the tree and it is not welcome to have categories with small >> number of packages. Other rust stuff will appear, but later (with >> no estimate), as a number of problems with packaging source rust >> packages should be solved before (afaik upstream also has plans >> to improve rust packaging). The same about moving source cargo to >> the tree. >> >> So what is better, create dev-util/cargo-bin package and later, >> when rust infrastructure grows, move it to the dev-rust category >> or create new category now? >> >> [1] https://crates.io/ [2] >> https://github.com/Heather/gentoo-rust >> >> -- Jauhien >> > > I think cargo should probably go in dev-util with other rust > libraries and programs going into dev-rust as needed, but that's > just me :D Agreed. dev-util until it grows in size (isn't the recommendation 5-10+ pkgs?), then dev-rust. Despite the package moves being somewhat cumbersome, it makes more sense to do it once it's clear Rust has an ecosystem going rather than catch stragglers in its infancy. For platform-specific things like compilers, dev-lang/ may be a better candidate. Just my 2¢. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV610xAAoJEAEkDpRQOeFw/RwQAJZfazVJ5hXgLUKDnsLS4fEX qVtUoacuC5CCXrcfqFcH5joYdhRAjFkM1AsS1zmGac7Ew3rLBuZZeZmOEror7NL9 LaNqWkLNGNjOWmg+R3fE+LpsiBfl2iD4taCdlZ9W4Qv2gSV2gsWhHRgCM3n6MtqB hg4y9INeUauEkwKiTqTr8ZBoqSmo49t+isbytQQfGS22SLZXVK7iQny7w/NR7vr6 dVgbURa/+fLOaPGd3+O66zj1CD40bpohLmcgbXELkOfe5x+P7ngAUq0SBqytzI7b nex6Jx+7ioQtyl8DEg22M16EIuF7t7/ySetI0Dd2SgurapzxAykIJcgrU8FvBxOi k5buTcqSXcf2GQqqDQJyFFUIqf4BT9H5cM+7MkDNiQFqck8UkA8uVMSbWGw5E+Po /6zfaXkBBOZlt6eH55XFdCGouSdAD/Pu7bNQ+GEswRWqSs3CQ9SkibRxr/d8rV85 1uipXSH8wcVPgOWoM2gIhBydGP6nqBjS4DHiPF9HL5felAdErTmk6tdnAxAkfey7 DVUdmMG5rjaOorpFHYvujTufUO3BYDXf0eA8ImR6jwok4Sfm2UR0xfReBGmNpNz6 lDa3kC3q0x5iU9vBv3NvhAH/mG/J9lE2BAxyS0F00l/4ykf2bMKSjqfrLLIpTUcb bW5RmPOk9vVc7GSKSdox =cMLX -END PGP SIGNATURE-
