[gentoo-dev] [RFC] New eclass patches.eclass

[gentoo-dev] [RFC] New eclass patches.eclass

[Vadim A. Misbakh-Soloviov]

[-- Attachment #1.1: Type: text/plain, Size: 354 bytes --]

HI there!

Some time ago I invented patches.eclass, which facilitates my work with 
patches, and I would like you to express your opinion about it and whether it 
is worth committing in gentoo repo.

Maybe it’s even worth it to become a helper, but not an eclass, or be bundled 
somewhere in existing eclasses/helpers.

-- 
Best regards,
mva

[-- Attachment #1.2: patches.eclass --]
[-- Type: text/plain, Size: 1968 bytes --]

# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

# @ECLASS: patches.eclass
# @MAINTAINER:
# mva
# @AUTHOR:
# mva
# @BLURB:
# @DESCRIPTION:
# Eclass that checks for patches directories existance and auto-add them into PATCHES=()

EXPORT_FUNCTIONS src_prepare


patches_src_prepare() {
	[[ -z ${PATCHES[@]} ]] && PATCHES=()
	PATCHDIR_BASE="${FILESDIR}/patches"
	PATCHDIRS=("${CUSTOM_PATCHDIR:-non-existant-dir}" "${SLOT//\/*}" "${PV}" "${PV}-${PR}")
	for PATCHDIR in ${PATCHDIRS[@]/#/${PATCHDIR_BASE}/}; do
		if [[ -d "${PATCHDIR}" ]]; then
			_patchdir_not_empty() {
				local has_files
				local LC_ALL=POSIX
				local prev_shopt=$(shopt -p nullglob)
				shopt -s nullglob
				local f
				local lvl=${2}
				for f in "${1:-${PATCHDIR}}"/*; do
					if [[ "${f}" == *.diff || "${f}" == *.patch ]] && [[ -f "${f}" || -L "${f}" ]]; then
						has_files=1
					elif [[ -d "${f}" ]] && [[ "${lvl:-0}" -eq 0 ]]; then
						# limit recursion to first level only,
						# since eapply cannot into recursion,
						# while 2-lvl "conditional" patching implemented below
						let lvl+=1
						_patchdir_not_empty "${f}" "${lvl}" && has_files=1
					fi
				done
				${prev_shopt}
				[[ -n "${has_files}" ]]; return $?
			}

			_patchdir_not_empty && PATCHES+=("${PATCHDIR}")

			if [[ -d "${PATCHDIR}/conditional" ]]; then
				pushd "${PATCHDIR}/conditional" &>/dev/null
				for d in *; do
					if [[ -d ${d} ]]; then
						if [[ "${d##no-}" == ${d} ]]; then
							(use "${d}" && _patchdir_not_empty "${d}") && PATCHES+=("${PATCHDIR}/conditional/${d}")
						else
							(use "${d##no-}" && _patchdir_not_empty "${d}") || PATCHES+=("${PATCHDIR}/conditional/${d}")
						fi
					fi
				done
				popd &>/dev/null
			fi
		fi
	done
	if declare -f cmake-utils_src_prepare &>/dev/null; then
		# cmake-utils_src_prepare support (to decrease kludges in the ebuilds)
		cmake-utils_src_prepare
	else
		default_src_prepare
	fi
}

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: [gentoo-dev] [RFC] New eclass patches.eclass

[David Seifert]

On Sun, 2019-12-22 at 16:39 +0700, Vadim A. Misbakh-Soloviov wrote:
> HI there!
> 
> Some time ago I invented patches.eclass, which facilitates my work
> with 
> patches, and I would like you to express your opinion about it and
> whether it 
> is worth committing in gentoo repo.
> 
> Maybe it’s even worth it to become a helper, but not an eclass, or be
> bundled 
> somewhere in existing eclasses/helpers.
> 

It seems your eclass is truncated.

Anyhow, this eclass contains too much implicit magic, so we won't be
able to include it in the tree.

Re: [gentoo-dev] [RFC] New eclass patches.eclass

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

On Sun, Dec 22, 2019 at 04:39:36PM +0700, Vadim A. Misbakh-Soloviov wrote:
> HI there!
> 
> Some time ago I invented patches.eclass, which facilitates my work with 
> patches, and I would like you to express your opinion about it and whether it 
> is worth committing in gentoo repo.
While I like it for ease of rapid development, conceptually, this
worries me.

Presently, if you add a new patch, you need to edit an ebuild, which
provides a strong hint that you might need to revbump the ebuild per
development best practices:
https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html

If this eclass was used, there would no longer be revbumps, and you
could not revert to the old version simply by reinstalling the prior
version.

Is there a way we can get the best of both worlds?

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

Re: [gentoo-dev] [RFC] New eclass patches.eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]

On Sun, 2019-12-22 at 16:39 +0700, Vadim A. Misbakh-Soloviov wrote:
> HI there!
> 
> Some time ago I invented patches.eclass, which facilitates my work with 
> patches, and I would like you to express your opinion about it and whether it 
> is worth committing in gentoo repo.
> 
> Maybe it’s even worth it to become a helper, but not an eclass, or be bundled 
> somewhere in existing eclasses/helpers.
> 

No.  This is just awful implicit magic.  While I understand that you
believe it makes the work easier for *you* but you are not going to be
the only person ever to touch ebuilds you are maintaining today.  You
are talking of creating a complex directory structure which might or
might not affect every ebuild, in hardly predictable ways.

Sometimes you won't be able to fit a patch in any of the categories. 
Then you're going to needlessly duplicate it in multiple directories,
triggering CI warnings for duplicate files.

Sometimes you will have to jump through hoops to change patching order,
so that every subdirectory works correctly.

Grepping the ebuilds for applicable files from FILESDIR just won't work.
Sure, maybe the proposed structure will be more convenient for cleanup. 
Unless people accidentally remove whole FILESDIR because they don't see
any reference to it.

Until this is widely deployed (which is unlikely to happen), people will
get very confused over every ebuild using it.

Finally, this can only bring real gain if you carry a lot of patches. 
In that case, I'd really prefer if you put them into a tarball, and into
SRC_URI rather than polluting all the Gentoo installations.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]