[gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

[gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

[Ulrich Müller]

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

The package split between app-editors/emacs for regular ebuilds and
app-editors/emacs-vcs for live ebuilds has outlived its usefulness, and
it entails additional maintenance effort to keep the two packages (e.g.,
the list of their use flags in metadata.xml) synchronised.

Therefore, consolidate all GNU Emacs ebuilds in a single package. Now is
a good time to do this change, because no further releases of Emacs 26
are to be expected, and the release cycle of Emacs 27 hasn't started
yet.

So, the plan is:

- Copy the live ebuilds into separate slots of app-editors/emacs (done).

- Update all reverse dependencies to depend on app-editors/emacs:*
  directly, instead of virtual/emacs. Since we allow switching the
  version with eselect, this includes a ":*" type slot dependency.
  No revbumps will be done for this (and virtual/emacs will be simply
  removed without prior masking). See patches 2 and 3 of this series.

- This allows NEED_EMACS to be more fine-grained and include the minor
  version. Therefore, elisp-need-emacs() from elisp-common.eclass
  switches to ver_test() for version comparison, instead of comparing
  the major version only. See patch 1 of this series.

- Package mask app-editors/emacs-vcs (but not the virtual) for removal.

Ulrich Müller (3):
  elisp-common.eclass: Allow full versions in elisp-need-emacs().
  elisp-common.eclass: Update documentation.
  elisp.eclass: Depend on app-editors/emacs directly.

 eclass/elisp-common.eclass | 36 +++++++++++++++++++-----------------
 eclass/elisp.eclass        |  4 ++--
 2 files changed, 21 insertions(+), 19 deletions(-)

-- 
2.24.1

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

[gentoo-dev] [PATCH 1/3] elisp-common.eclass: Allow full versions in elisp-need-emacs().

[Ulrich Müller]

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

To this end, replace the simple numeric comparison of the first
component by a call to ver_test.

Signed-off-by: Ulrich Müller <ulm@gentoo.org>
---
 eclass/elisp-common.eclass | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/eclass/elisp-common.eclass b/eclass/elisp-common.eclass
index 79f29ef95ad..6f79caee2f0 100644
--- a/eclass/elisp-common.eclass
+++ b/eclass/elisp-common.eclass
@@ -158,7 +158,8 @@
 # merge and unmerge of a package.
 
 case ${EAPI:-0} in
-	4|5|6|7) ;;
+	4|5|6) inherit eapi7-ver ;;
+	7) ;;
 	*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
@@ -230,11 +231,16 @@ elisp-need-emacs() {
 	have_emacs=$(elisp-emacs-version) || return 2
 	einfo "Emacs version: ${have_emacs}"
 	if [[ ${have_emacs} =~ XEmacs|Lucid ]]; then
-		eerror "This package needs GNU Emacs."
+		eerror "XEmacs detected. This package needs GNU Emacs."
 		return 1
 	fi
-	if ! [[ ${have_emacs%%.*} -ge ${need_emacs%%.*} ]]; then
-		eerror "This package needs at least Emacs ${need_emacs%%.*}."
+	# GNU Emacs versions have only numeric components.
+	if ! [[ ${have_emacs} =~ ^[0-9]+(\.[0-9]+)*$ ]]; then
+		eerror "Malformed version string: ${have_emacs}"
+		return 2
+	fi
+	if ! ver_test "${have_emacs}" -ge "${need_emacs}"; then
+		eerror "This package needs at least Emacs ${need_emacs}."
 		eerror "Use \"eselect emacs\" to select the active version."
 		return 1
 	fi
-- 
2.24.1

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

[gentoo-dev] [PATCH 2/3] elisp-common.eclass: Update documentation.

[Ulrich Müller]

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

After the package split between emacs and emacs-vcs is gone, packages
can depend on app-editors/emacs directly.

Signed-off-by: Ulrich Müller <ulm@gentoo.org>
---
 eclass/elisp-common.eclass | 22 +++++++++-------------
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/eclass/elisp-common.eclass b/eclass/elisp-common.eclass
index 6f79caee2f0..47e33ac28ae 100644
--- a/eclass/elisp-common.eclass
+++ b/eclass/elisp-common.eclass
@@ -24,26 +24,26 @@
 # When relying on the emacs USE flag, you need to add
 #
 # @CODE
-# 	emacs? ( virtual/emacs )
+# 	emacs? ( app-editors/emacs:* )
 # @CODE
 #
 # to your DEPEND/RDEPEND line and use the functions provided here to
 # bring the files to the correct locations.
 #
-# If your package requires a minimum Emacs version, e.g. Emacs 24, then
-# the dependency should be on >=virtual/emacs-24 instead.  Because the
-# user can select the Emacs executable with eselect, you should also
-# make sure that the active Emacs version is sufficient.  This can be
-# tested with function elisp-need-emacs(), which would typically be
-# called from pkg_setup(), as in the following example:
+# If your package requires a minimum Emacs version, e.g. Emacs 26.1,
+# then the dependency should be on >=app-editors/emacs-26.1:* instead.
+# Because the user can select the Emacs executable with eselect, you
+# should also make sure that the active Emacs version is sufficient.
+# This can be tested with function elisp-need-emacs(), which would
+# typically be called from pkg_setup(), as in the following example:
 #
 # @CODE
-# 	elisp-need-emacs 24 || die "Emacs version too low"
+# 	elisp-need-emacs 26.1 || die "Emacs version too low"
 # @CODE
 #
 # Please note that such tests should be limited to packages that are
 # known to fail with lower Emacs versions; the standard case is to
-# depend on virtual/emacs without version.
+# depend on app-editors/emacs without version.
 #
 # @ROFF .SS
 # src_compile() usage:
@@ -152,10 +152,6 @@
 #
 # When having optional Emacs support, you should prepend "use emacs &&"
 # to above calls of elisp-site-regen().
-# Don't use "has_version virtual/emacs"!  When unmerging the state of
-# the emacs USE flag is taken from the package database and not from the
-# environment, so it is no problem when you unset USE=emacs between
-# merge and unmerge of a package.
 
 case ${EAPI:-0} in
 	4|5|6) inherit eapi7-ver ;;
-- 
2.24.1

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

[gentoo-dev] [PATCH 3/3] elisp.eclass: Depend on app-editors/emacs directly.

[Ulrich Müller]

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

This replaces the indirect dependency on virtual/emacs.

Signed-off-by: Ulrich Müller <ulm@gentoo.org>
---
 eclass/elisp.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/elisp.eclass b/eclass/elisp.eclass
index df160ea01e2..8f907bbb5d6 100644
--- a/eclass/elisp.eclass
+++ b/eclass/elisp.eclass
@@ -70,7 +70,7 @@ esac
 EXPORT_FUNCTIONS src_{unpack,prepare,configure,compile,install} \
 	pkg_{setup,postinst,postrm}
 
-RDEPEND=">=virtual/emacs-${NEED_EMACS:-23}"
+RDEPEND=">=app-editors/emacs-${NEED_EMACS:-23.1}:*"
 case ${EAPI} in
 	4|5|6) DEPEND="${RDEPEND}" ;;
 	*) BDEPEND="${RDEPEND}" ;;
@@ -82,7 +82,7 @@ esac
 # version requirement of the NEED_EMACS variable.
 
 elisp_pkg_setup() {
-	elisp-need-emacs "${NEED_EMACS:-23}"
+	elisp-need-emacs "${NEED_EMACS:-23.1}"
 	case $? in
 		0) ;;
 		1) die "Emacs version too low" ;;
-- 
2.24.1

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

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

[Michał Górny]

Dnia December 18, 2019 11:08:16 AM UTC, "Ulrich Müller" <ulm@gentoo.org> napisał(a):
>The package split between app-editors/emacs for regular ebuilds and
>app-editors/emacs-vcs for live ebuilds has outlived its usefulness, and
>it entails additional maintenance effort to keep the two packages
>(e.g.,
>the list of their use flags in metadata.xml) synchronised.
>
>Therefore, consolidate all GNU Emacs ebuilds in a single package. Now
>is
>a good time to do this change, because no further releases of Emacs 26
>are to be expected, and the release cycle of Emacs 27 hasn't started
>yet.
>
>So, the plan is:
>
>- Copy the live ebuilds into separate slots of app-editors/emacs
>(done).
>
>- Update all reverse dependencies to depend on app-editors/emacs:*
>  directly, instead of virtual/emacs. Since we allow switching the
>  version with eselect, this includes a ":*" type slot dependency.
>  No revbumps will be done for this (and virtual/emacs will be simply
>  removed without prior masking). See patches 2 and 3 of this series.
>
>- This allows NEED_EMACS to be more fine-grained and include the minor
>  version. Therefore, elisp-need-emacs() from elisp-common.eclass
>  switches to ver_test() for version comparison, instead of comparing
>  the major version only. See patch 1 of this series.
>
>- Package mask app-editors/emacs-vcs (but not the virtual) for removal.

Maybe package.deprecated the virtual? 

>
>Ulrich Müller (3):
>  elisp-common.eclass: Allow full versions in elisp-need-emacs().
>  elisp-common.eclass: Update documentation.
>  elisp.eclass: Depend on app-editors/emacs directly.
>
> eclass/elisp-common.eclass | 36 +++++++++++++++++++-----------------
> eclass/elisp.eclass        |  4 ++--
> 2 files changed, 21 insertions(+), 19 deletions(-)


--
Best regards, 
Michał Górny

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

[Ulrich Mueller]

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

>>>>> On Wed, 18 Dec 2019, Michał Górny wrote:

>> - Package mask app-editors/emacs-vcs (but not the virtual) for removal.

> Maybe package.deprecated the virtual?

Good idea. I have to get used to this. :-)

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

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

[Michael Orlitzky]

On 12/18/19 6:08 AM, Ulrich Müller wrote:
>   No revbumps will be done for this (and virtual/emacs will be simply
>   removed without prior masking).
I guess it's nice that we know ahead of time, but is there any reason to
suspect that this won't cause havoc?

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

[Ulrich Mueller]

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

>>>>> On Wed, 18 Dec 2019, Michael Orlitzky wrote:

>> No revbumps will be done for this (and virtual/emacs will be simply
>> removed without prior masking).

> I guess it's nice that we know ahead of time, but is there any reason
> to suspect that this won't cause havoc?

Removal of the virtual/emacs ebuilds won't remove the installed package
from users' systems. It will eventually disappear, when all its reverse
dependencies have been updated. Why would its continued presence as an
installed package (for another while) cause any problems?

Revbumping its more than 400 reverse dependencies really doesn't sound
so attractive, and would cause rebuilds on users' systems for virtually
(pun intended :-) no benefit.

Ulrich

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

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

[Michael Orlitzky]

On 12/18/19 11:34 AM, Ulrich Mueller wrote:
> 
> Removal of the virtual/emacs ebuilds won't remove the installed package
> from users' systems. It will eventually disappear, when all its reverse
> dependencies have been updated. Why would its continued presence as an
> installed package (for another while) cause any problems?

Unless the VDB is updated, portage will see a dependency on a package
that doesn't exist and could refuse to do a lot of things like a @world
update involving a rebuild of one of those packages, or a --depclean.

This *does* happen if you mask virtual/emacs. It *could* happen if you
delete it.


> Revbumping its more than 400 reverse dependencies really doesn't sound
> so attractive, and would cause rebuilds on users' systems for virtually
> (pun intended :-) no benefit.

If portage bails on an update and I have to troubleshoot the problem for
ten minutes, then that's already wasted more of my time than if it
reinstalled all 400 revdeps. The benefit is that people don't get
cryptic messages from a confused packaged manager that they have to
debug all day.

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

[Michael Orlitzky]

On 12/18/19 6:28 PM, Michael Orlitzky wrote:
> 
> This *does* happen if you mask virtual/emacs. It *could* happen if you
> delete it.
> 

I tested this out.

Portage seems OK with the missing dependency, but for the overall plan
to work, you have to wait a long time before deleting virtual/emacs;
otherwise the upgrade path is broken. With virtual/emacs-26 installed
and "old" copies of the elisp ebuilds installed, you get unsatisfied
dependencies switching from emacs-vcs to a live slot of emacs. Everyone
in that situation must update to virtual/emacs-26-r1, which they can't
do after you delete it.

And of course you can't mask virtual/emacs in the meantime, because that
does kill the PM.

New revisions would still be the sane solution, now and in the future,
because they don't require investigative journalism to uncover exactly
what might go wrong when we bend the rules /this time/. They also don't
impose a cutoff date after which upgrading users are screwed. You just
automate the revbumps, commit them all at once, and make a pull request
against CI to verify that nothing is too borked.

[gentoo-dev] [PATCH v2 1/3] elisp-common.eclass: New function elisp-check-emacs-version.

[Ulrich Müller]

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

Tests if the Emacs version is at least the (full) version specified
by NEED_EMACS, otherwise dies. Intended as a replacement for function
elisp-need-emacs, which did only a simple numeric comparison of the
major version.

Call the new function before doing any actual work in elisp-compile()
and elisp-make-autoload-file(), so ebuilds inheriting only
elisp-common.eclass (but not elisp.eclass) won't have to add a
pkg_setup phase function.

Drop support for EAPIs 0 to 3.

Signed-off-by: Ulrich Müller <ulm@gentoo.org>
---
v2: Don't change elisp-need-emacs() in place, but add a new function
    for the new functionality, and and deprecate the old function.

 eclass/elisp-common.eclass | 52 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/eclass/elisp-common.eclass b/eclass/elisp-common.eclass
index 05b03f49395..8e5d70046bc 100644
--- a/eclass/elisp-common.eclass
+++ b/eclass/elisp-common.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: elisp-common.eclass
@@ -156,6 +156,12 @@
 # environment, so it is no problem when you unset USE=emacs between
 # merge and unmerge of a package.
 
+case ${EAPI:-0} in
+	4|5|6) inherit eapi7-ver ;;
+	7) ;;
+	*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
 # @ECLASS-VARIABLE: SITELISP
 # @DESCRIPTION:
 # Directory where packages install Emacs Lisp files.
@@ -182,6 +188,17 @@ EMACSFLAGS="-batch -q --no-site-file"
 # Emacs flags used for byte-compilation in elisp-compile().
 BYTECOMPFLAGS="-L ."
 
+# @ECLASS-VARIABLE: NEED_EMACS
+# @DESCRIPTION:
+# The minimum Emacs version required for the package.
+: ${NEED_EMACS:=23.1}
+
+# @ECLASS-VARIABLE: _ELISP_EMACS_VERSION
+# @INTERNAL
+# @DESCRIPTION:
+# Cached value of Emacs version detected in elisp-check-emacs-version().
+_ELISP_EMACS_VERSION=""
+
 # @FUNCTION: elisp-emacs-version
 # @RETURN: exit status of Emacs
 # @DESCRIPTION:
@@ -212,6 +229,35 @@ elisp-emacs-version() {
 	echo "${version}"
 }
 
+# @FUNCTION: elisp-check-emacs-version
+# @USAGE: [version]
+# @DESCRIPTION:
+# Test if the eselected Emacs version is at least the version of
+# GNU Emacs specified in the NEED_EMACS variable, or die otherwise.
+
+elisp-check-emacs-version() {
+	if [[ -z ${_ELISP_EMACS_VERSION} ]]; then
+		local have_emacs
+		have_emacs=$(elisp-emacs-version) \
+			|| die "Could not determine Emacs version"
+		elog "Emacs version: ${have_emacs}"
+		if [[ ${have_emacs} =~ XEmacs|Lucid ]]; then
+			die "XEmacs detected. This package needs GNU Emacs."
+		fi
+		# GNU Emacs versions have only numeric components.
+		if ! [[ ${have_emacs} =~ ^[0-9]+(\.[0-9]+)*$ ]]; then
+			die "Malformed version string: ${have_emacs}"
+		fi
+		_ELISP_EMACS_VERSION=${have_emacs}
+	fi
+
+	if ! ver_test "${_ELISP_EMACS_VERSION}" -ge "${NEED_EMACS}"; then
+		eerror "This package needs at least Emacs ${NEED_EMACS}."
+		eerror "Use \"eselect emacs\" to select the active version."
+		die "Emacs version too low"
+	fi
+}
+
 # @FUNCTION: elisp-need-emacs
 # @USAGE: <version>
 # @RETURN: 0 if true, 1 if false, 2 if trouble
@@ -249,6 +295,8 @@ elisp-need-emacs() {
 # in case they require or load one another.
 
 elisp-compile() {
+	elisp-check-emacs-version
+
 	ebegin "Compiling GNU Emacs Elisp files"
 	${EMACS} ${EMACSFLAGS} ${BYTECOMPFLAGS} -f batch-byte-compile "$@"
 	eend $? "elisp-compile: batch-byte-compile failed" || die
@@ -262,6 +310,8 @@ elisp-compile() {
 elisp-make-autoload-file() {
 	local f="${1:-${PN}-autoloads.el}" null="" page=$'\f'
 	shift
+	elisp-check-emacs-version
+
 	ebegin "Generating autoload file for GNU Emacs"
 
 	cat >"${f}" <<-EOF
-- 
2.24.1

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

[gentoo-dev] [PATCH v2 2/3] elisp-common.eclass: Update documentation.

[Ulrich Müller]

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

After the package split between emacs and emacs-vcs is gone, packages
can depend on app-editors/emacs directly.

Deprecate function elisp-need-emacs; ebuilds should assign variable
NEED_EMACS instead.

Signed-off-by: Ulrich Müller <ulm@gentoo.org>
---
 eclass/elisp-common.eclass | 45 ++++++++++++++++++++++----------------
 1 file changed, 26 insertions(+), 19 deletions(-)

diff --git a/eclass/elisp-common.eclass b/eclass/elisp-common.eclass
index 8e5d70046bc..aac50fc65f0 100644
--- a/eclass/elisp-common.eclass
+++ b/eclass/elisp-common.eclass
@@ -23,26 +23,25 @@
 # When relying on the emacs USE flag, you need to add
 #
 # @CODE
-# 	emacs? ( virtual/emacs )
+# 	emacs? ( >=app-editors/emacs-23.1:* )
 # @CODE
 #
 # to your DEPEND/RDEPEND line and use the functions provided here to
 # bring the files to the correct locations.
 #
-# If your package requires a minimum Emacs version, e.g. Emacs 24, then
-# the dependency should be on >=virtual/emacs-24 instead.  Because the
-# user can select the Emacs executable with eselect, you should also
-# make sure that the active Emacs version is sufficient.  This can be
-# tested with function elisp-need-emacs(), which would typically be
-# called from pkg_setup(), as in the following example:
+# If your package requires a minimum Emacs version, e.g. Emacs 26.1,
+# then the dependency should be on >=app-editors/emacs-26.1:* instead.
+# Because the user can select the Emacs executable with eselect, you
+# should also make sure that the active Emacs version is sufficient.
+# The eclass will automatically ensure this if you assign variable
+# NEED_EMACS with the Emacs version, as in the following example:
 #
 # @CODE
-# 	elisp-need-emacs 24 || die "Emacs version too low"
+# 	NEED_EMACS=26.1
 # @CODE
 #
-# Please note that such tests should be limited to packages that are
-# known to fail with lower Emacs versions; the standard case is to
-# depend on virtual/emacs without version.
+# Please note that this should be done only for packages that are known
+# to fail with lower Emacs versions.
 #
 # @ROFF .SS
 # src_compile() usage:
@@ -134,6 +133,20 @@
 # the differing name as second argument.
 #
 # @ROFF .SS
+# pkg_setup() usage:
+#
+# If your ebuild uses the elisp-compile eclass function to compile
+# its elisp files (see above), then you don't need a pkg_setup phase,
+# because elisp-compile and elisp-make-autoload-file do their own sanity
+# checks.  On the other hand, if the elisp files are compiled by the
+# package's build system, then there is often no check for the Emacs
+# version.  In this case, you can add an explicit check in pkg_setup:
+#
+# @CODE
+# 	elisp-check-emacs-version
+# @CODE
+#
+# @ROFF .SS
 # pkg_postinst() / pkg_postrm() usage:
 #
 # After that you need to recreate the start-up file of Emacs after
@@ -151,10 +164,6 @@
 #
 # When having optional Emacs support, you should prepend "use emacs &&"
 # to above calls of elisp-site-regen().
-# Don't use "has_version virtual/emacs"!  When unmerging the state of
-# the emacs USE flag is taken from the package database and not from the
-# environment, so it is no problem when you unset USE=emacs between
-# merge and unmerge of a package.
 
 case ${EAPI:-0} in
 	4|5|6) inherit eapi7-ver ;;
@@ -258,12 +267,10 @@ elisp-check-emacs-version() {
 	fi
 }
 
-# @FUNCTION: elisp-need-emacs
-# @USAGE: <version>
-# @RETURN: 0 if true, 1 if false, 2 if trouble
-# @DESCRIPTION:
 # Test if the eselected Emacs version is at least the major version
 # of GNU Emacs specified as argument.
+# Return 0 if true, 1 if false, 2 if trouble.
+# Deprecated, use elisp-check-emacs-version instead.
 
 elisp-need-emacs() {
 	local need_emacs=$1 have_emacs
-- 
2.24.1

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

[gentoo-dev] [PATCH v2 3/3] elisp.eclass: Depend on app-editors/emacs directly.

[Ulrich Müller]

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

This replaces the indirect dependency on virtual/emacs.

Update pkg_setup() to call elisp-check-emacs-version instead of the
now deprecated elisp-need-emacs.

Signed-off-by: Ulrich Müller <ulm@gentoo.org>
---
 eclass/elisp.eclass | 15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/eclass/elisp.eclass b/eclass/elisp.eclass
index df160ea01e2..2b50111a535 100644
--- a/eclass/elisp.eclass
+++ b/eclass/elisp.eclass
@@ -30,8 +30,8 @@
 # @DEFAULT_UNSET
 # @DESCRIPTION:
 # If you need anything different from Emacs 23, use the NEED_EMACS
-# variable before inheriting elisp.eclass.  Set it to the major version
-# your package uses and the dependency will be adjusted.
+# variable before inheriting elisp.eclass.  Set it to the version your
+# package uses and the dependency will be adjusted.
 
 # @ECLASS-VARIABLE: ELISP_PATCHES
 # @DEFAULT_UNSET
@@ -70,7 +70,7 @@ esac
 EXPORT_FUNCTIONS src_{unpack,prepare,configure,compile,install} \
 	pkg_{setup,postinst,postrm}
 
-RDEPEND=">=virtual/emacs-${NEED_EMACS:-23}"
+RDEPEND=">=app-editors/emacs-${NEED_EMACS}:*"
 case ${EAPI} in
 	4|5|6) DEPEND="${RDEPEND}" ;;
 	*) BDEPEND="${RDEPEND}" ;;
@@ -78,16 +78,11 @@ esac
 
 # @FUNCTION: elisp_pkg_setup
 # @DESCRIPTION:
-# Test if the eselected Emacs version is sufficient to fulfil the major
+# Test if the eselected Emacs version is sufficient to fulfil the
 # version requirement of the NEED_EMACS variable.
 
 elisp_pkg_setup() {
-	elisp-need-emacs "${NEED_EMACS:-23}"
-	case $? in
-		0) ;;
-		1) die "Emacs version too low" ;;
-		*) die "Could not determine Emacs version" ;;
-	esac
+	elisp-check-emacs-version
 }
 
 # @FUNCTION: elisp_src_unpack
-- 
2.24.1

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

Re: [gentoo-dev] [PATCH v2 3/3] elisp.eclass: Depend on app-editors/emacs directly.

[Ulrich Mueller]

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

> -RDEPEND=">=virtual/emacs-${NEED_EMACS:-23}"
> +RDEPEND=">=app-editors/emacs-${NEED_EMACS}:*"

... and of course, the slot operator isn't legal in EAPI 4. It is
trivial to fix, so I won't send a v3 for this.

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

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

[Ulrich Mueller]

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

>>>>> On Fri, 20 Dec 2019, Michael Orlitzky wrote:

> Portage seems OK with the missing dependency, but for the overall plan
> to work, you have to wait a long time before deleting virtual/emacs;
> otherwise the upgrade path is broken. With virtual/emacs-26 installed
> and "old" copies of the elisp ebuilds installed, you get unsatisfied
> dependencies switching from emacs-vcs to a live slot of emacs. Everyone
> in that situation must update to virtual/emacs-26-r1, which they can't
> do after you delete it.

> And of course you can't mask virtual/emacs in the meantime, because that
> does kill the PM.

I have no plans of masking the virtual. It will be simply removed,
presumably after the app-editors/emacs-27.1 release (at which point any
emacs-vcs-27.0* will be outdated, and be blocked against by the ebuild).

> New revisions would still be the sane solution, now and in the future,
> because they don't require investigative journalism to uncover exactly
> what might go wrong when we bend the rules /this time/. They also don't
> impose a cutoff date after which upgrading users are screwed. You just
> automate the revbumps, commit them all at once, and make a pull request
> against CI to verify that nothing is too borked.

See? You say it yourself, with 400 revbumps there is quite some chance
for breakage.

Ulrich

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

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

[Michael Orlitzky]

On 12/21/19 1:57 AM, Ulrich Mueller wrote:
> 
> See? You say it yourself, with 400 revbumps there is quite some chance
> for breakage.
> 

I was being safe, and assuming that your standards for shell scripting
are as low as your standards for tree quality.

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

[Ulrich Mueller]

>>>>> On Sat, 21 Dec 2019, Michael Orlitzky wrote:

> I was being safe, and assuming that your standards for shell scripting
> are as low as your standards for tree quality.

Nice, resorting to a personal attack when out of arguments. :(

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

[Michael Orlitzky]

On 12/21/19 6:39 AM, Ulrich Mueller wrote:
>>>>>> On Sat, 21 Dec 2019, Michael Orlitzky wrote:
> 
>> I was being safe, and assuming that your standards for shell scripting
>> are as low as your standards for tree quality.
> 
> Nice, resorting to a personal attack when out of arguments. :(
> 

I'm not out of arguments because you haven't addressed any of them. You
just said you were going to ignore the policy and break things anyway.
And then you tried to use my suggestion to be extra careful and run a CI
check against me, which is obnoxious, so there you go.

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

[Michael Orlitzky]

On 12/21/19 6:39 AM, Ulrich Mueller wrote:
>>>>>> On Sat, 21 Dec 2019, Michael Orlitzky wrote:
> 
>> I was being safe, and assuming that your standards for shell scripting
>> are as low as your standards for tree quality.
> 
> Nice, resorting to a personal attack when out of arguments. :(
> 

And for the record, commenting on standards in response to a series of
commits that display low standards is not a personal attack.

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

[Ulrich Mueller]

>>>>> On Sat, 21 Dec 2019, Michael Orlitzky wrote:

> And then you tried to use my suggestion to be extra careful and run a
> CI check against me, which is obnoxious, so there you go.

Maybe you shouldn't suggest usage of non-free tools (like Github) then?
It's everyone's own choice if they want to use such tools, but it
certainly cannot be part of any standard workflow.

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

[Ulrich Mueller]

>>>>> On Sat, 21 Dec 2019, Michael Orlitzky wrote:

> And for the record, commenting on standards in response to a series of
> commits that display low standards is not a personal attack.

*shrug* As a matter of fact, I've run that series of commits past the
QA lead, who has approved them.

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

[Michael 'veremitz' Everitt]

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

On 21/12/19 11:52, Ulrich Mueller wrote:
>>>>>> On Sat, 21 Dec 2019, Michael Orlitzky wrote:
>> And for the record, commenting on standards in response to a series of
>> commits that display low standards is not a personal attack.
> *shrug* As a matter of fact, I've run that series of commits past the
> QA lead, who has approved them.
>
FWIW, the QA lead doesn't always reflect the opinion of the whole QA team ..


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]