Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Mon, 2022-06-13 at 11:30 +0200, Florian Schmaus wrote: > On 13/06/2022 10.29, Michał Górny wrote: > > On Mon, 2022-06-13 at 09:44 +0200, Florian Schmaus wrote: > > > Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM, > > > where some voices where in agreement that EGO_SUM has its raison d'être, > > > while there where no arguments in favor of eventually removing EGO_SUM, > > > I hereby propose to undeprecate EGO_SUM. > > > > > > 1: > > > https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa > > > > > > > "We've been rehashing the discussion until all opposition got tired > > and stopped replying, then we claim everyone agrees". > > I understand this comment so that there was already a discussion about > deprecating and removing EGO_SUM. I usually try to follow what's going > on Gentoo and I remember the discussion about introducing dependency > tarballs. But I apparently have missed the part where EGO_SUM was slated > for removal. And it appears I am not the only one, at least Ionen also > wrote "Missed bits and pieces but was never quite sure why this went > toward full deprecation, just discouraged may have been fair enough, …". > > In any case, I am sorry for bringing this discussion up again. But since > I started rehashing this, no arguments why EGO_SUM should be removed > have been provided. And so far, I failed to find the old discussions > where I'd hope to find some rationale behind the deprecation of EGO_SUM. :/ > I disagree. Robin has made a pretty complete summary in his mail, with numbers that prove how bad EGO_SUM is/was [1]. While he may have disagreed with dependency tarballs, he brought pretty clear arguments how EGO_SUM is even worse. Multiplied by all the Gentoo systems that won't ever install 95% of Go packages, yet all have to carry their overhead. [1] https://archives.gentoo.org/gentoo-dev/message/8e2a4002bfc6258d65dcf725db347cb9 -- Best regards, Michał Górny
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
> On Mon, 13 Jun 2022, Florian Schmaus wrote: Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM, where some voices where in agreement that EGO_SUM has its raison d'être, while there where no arguments in favor of eventually removing EGO_SUM, I hereby propose to undeprecate EGO_SUM. 1: https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa >> Can this be done without requesting changes to package managers? > What is 'this' here? Undeprecating EGO_SUM. > The patchset does not make changes to any package manager, just the > go-module eclass. > Note that this is not about finding about an alternative to dependency > tarballs. It is just about re-allowing EGO_SUM in addition to > dependency tarballs for packaging Go software in Gentoo. OK. Thanks for the clarification. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] go-module.eclass: undeprecate EGO_SUM
On 13/06/2022 11.49, Andrew Ammerlaan wrote: On 13/06/2022 09:44, Florian Schmaus wrote: Following the gentoo-dev@ mailing list discussion [1], this un-deprecates EGO_SUM. 1: https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa Signed-off-by: Florian Schmaus --- eclass/go-module.eclass | 30 +++--- 1 file changed, 11 insertions(+), 19 deletions(-) diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass index a5dafb45cab8..2e0b7dc1726d 100644 --- a/eclass/go-module.eclass +++ b/eclass/go-module.eclass @@ -25,7 +25,9 @@ # # If the software has a directory named vendor in its # top level directory, the only thing you need to do is inherit the -# eclass. If it doesn't, you need to also create a dependency tarball and +# eclass. If it doesn't, then you either 1) populate EGO_SUM in the ebuild and +# call go-module_set_globals as discussed below or 2) you need to create a +# dependency tarball and # host it somewhere, for example in your dev space. # # Here is an example of how to create a dependency tarball. I agree that EGO_SUM shouldn't have been completely deprecated following the previous discussion. It is not always possible or practical to host a dependency tarball, especially for people who aren't Gentoo developers. However, from what I remember from the previous discussion there actually were some good arguments against using EGO_SUM, mainly relating to the size of the ebuilds and manifests. What's wrong with an ebuild using an EGO_SUM with a few entries in ::gentoo? - Florian
Re: [gentoo-dev] [PATCH] go-module.eclass: undeprecate EGO_SUM
On 13/06/2022 09:44, Florian Schmaus wrote: Following the gentoo-dev@ mailing list discussion [1], this un-deprecates EGO_SUM. 1: https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa Signed-off-by: Florian Schmaus --- eclass/go-module.eclass | 30 +++--- 1 file changed, 11 insertions(+), 19 deletions(-) diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass index a5dafb45cab8..2e0b7dc1726d 100644 --- a/eclass/go-module.eclass +++ b/eclass/go-module.eclass @@ -25,7 +25,9 @@ # # If the software has a directory named vendor in its # top level directory, the only thing you need to do is inherit the -# eclass. If it doesn't, you need to also create a dependency tarball and +# eclass. If it doesn't, then you either 1) populate EGO_SUM in the ebuild and +# call go-module_set_globals as discussed below or 2) you need to create a +# dependency tarball and # host it somewhere, for example in your dev space. # # Here is an example of how to create a dependency tarball. I agree that EGO_SUM shouldn't have been completely deprecated following the previous discussion. It is not always possible or practical to host a dependency tarball, especially for people who aren't Gentoo developers. However, from what I remember from the previous discussion there actually were some good arguments against using EGO_SUM, mainly relating to the size of the ebuilds and manifests. So perhaps we can find some middle ground here and keep EGO_SUM for e.g. third-party repositories, while recommending dependency tarballs for use in ::gentoo. Could we add something among those lines to the text here? Best regards, Andrew
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On 13/06/2022 10.49, Ulrich Mueller wrote: On Mon, 13 Jun 2022, Michał Górny wrote: On Mon, 2022-06-13 at 09:44 +0200, Florian Schmaus wrote: Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM, where some voices where in agreement that EGO_SUM has its raison d'être, while there where no arguments in favor of eventually removing EGO_SUM, I hereby propose to undeprecate EGO_SUM. 1: https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa Can this be done without requesting changes to package managers? What is 'this' here? The patchset does not make changes to any package manager, just the go-module eclass. Note that this is not about finding about an alternative to dependency tarballs. It is just about re-allowing EGO_SUM in addition to dependency tarballs for packaging Go software in Gentoo. - Flow
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On 13/06/2022 10.29, Michał Górny wrote: On Mon, 2022-06-13 at 09:44 +0200, Florian Schmaus wrote: Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM, where some voices where in agreement that EGO_SUM has its raison d'être, while there where no arguments in favor of eventually removing EGO_SUM, I hereby propose to undeprecate EGO_SUM. 1: https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa "We've been rehashing the discussion until all opposition got tired and stopped replying, then we claim everyone agrees". I understand this comment so that there was already a discussion about deprecating and removing EGO_SUM. I usually try to follow what's going on Gentoo and I remember the discussion about introducing dependency tarballs. But I apparently have missed the part where EGO_SUM was slated for removal. And it appears I am not the only one, at least Ionen also wrote "Missed bits and pieces but was never quite sure why this went toward full deprecation, just discouraged may have been fair enough, …". In any case, I am sorry for bringing this discussion up again. But since I started rehashing this, no arguments why EGO_SUM should be removed have been provided. And so far, I failed to find the old discussions where I'd hope to find some rationale behind the deprecation of EGO_SUM. :/ - Flow
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
> On Mon, 13 Jun 2022, Michał Górny wrote: > On Mon, 2022-06-13 at 09:44 +0200, Florian Schmaus wrote: >> Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM, >> where some voices where in agreement that EGO_SUM has its raison d'être, >> while there where no arguments in favor of eventually removing EGO_SUM, >> I hereby propose to undeprecate EGO_SUM. >> >> 1: >> https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa Can this be done without requesting changes to package managers? Previous examples are unexporting variables because their size exceeds the limit of the Linux kernel [2], or introduction of additional phase functions that bypass Manifest validation [3]. > "We've been rehashing the discussion until all opposition got tired > and stopped replying, then we claim everyone agrees". [2] https://bugs.gentoo.org/721088 [3] https://bugs.gentoo.org/833567 signature.asc Description: PGP signature
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Mon, 2022-06-13 at 09:44 +0200, Florian Schmaus wrote: > Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM, > where some voices where in agreement that EGO_SUM has its raison d'être, > while there where no arguments in favor of eventually removing EGO_SUM, > I hereby propose to undeprecate EGO_SUM. > > 1: > https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa > "We've been rehashing the discussion until all opposition got tired and stopped replying, then we claim everyone agrees". -- Best regards, Michał Górny
[gentoo-dev] [PATCH] go-module.eclass: undeprecate EGO_SUM
Following the gentoo-dev@ mailing list discussion [1], this
un-deprecates EGO_SUM.
1:
https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa
Signed-off-by: Florian Schmaus
---
eclass/go-module.eclass | 30 +++---
1 file changed, 11 insertions(+), 19 deletions(-)
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index a5dafb45cab8..2e0b7dc1726d 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -25,7 +25,9 @@
#
# If the software has a directory named vendor in its
# top level directory, the only thing you need to do is inherit the
-# eclass. If it doesn't, you need to also create a dependency tarball and
+# eclass. If it doesn't, then you either 1) populate EGO_SUM in the ebuild and
+# call go-module_set_globals as discussed below or 2) you need to create a
+# dependency tarball and
# host it somewhere, for example in your dev space.
#
# Here is an example of how to create a dependency tarball.
@@ -52,9 +54,14 @@
#
# inherit go-module
#
+# EGO_SUM=(
+# "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59/go.mod"
+# "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59"
+# )
+#
+# go-mdoule_set_globals
# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
${P}.tar.gz"
-# Add this line if you have a dependency tarball.
-# SRC_URI+=" ${P}-deps.tar.xz"
+# SRC_URI+=" ${EGO_SUM_SRC_URI}"
#
# @CODE
@@ -105,11 +112,7 @@ QA_FLAGS_IGNORED='.*'
RESTRICT+=" strip"
# @ECLASS_VARIABLE: EGO_SUM
-# @DEPRECATED: none
# @DESCRIPTION:
-# This is replaced by a dependency tarball, see above for how to create
-# one.
-#
# This array is based on the contents of the go.sum file from the top
# level directory of the software you are packaging. Each entry must be
# quoted and contain the first two fields of a line from go.sum.
@@ -153,7 +156,6 @@ RESTRICT+=" strip"
# go.sum copy of the Hash1 values during building of the package.
# @ECLASS_VARIABLE: _GOMODULE_GOPROXY_BASEURI
-# @DEPRECATED: none
# @DESCRIPTION:
# Golang module proxy service to fetch module files from. Note that the module
# proxy generally verifies modules via the Hash1 code.
@@ -176,7 +178,6 @@ RESTRICT+=" strip"
: "${_GOMODULE_GOPROXY_BASEURI:=mirror://goproxy/}"
# @ECLASS_VARIABLE: _GOMODULE_GOSUM_REVERSE_MAP
-# @DEPRECATED: none
# @DESCRIPTION:
# Mapping back from Gentoo distfile name to upstream distfile path.
# Associative array to avoid O(N*M) performance when populating the GOPROXY
@@ -206,7 +207,6 @@ ego() {
}
# @FUNCTION: go-module_set_globals
-# @DEPRECATED: none
# @DESCRIPTION:
# Convert the information in EGO_SUM for other usage in the ebuild.
# - Populates EGO_SUM_SRC_URI that can be added to SRC_URI
@@ -297,7 +297,6 @@ go-module_set_globals() {
}
# @FUNCTION: go-module_setup_proxy
-# @DEPRECATED: none
# @DESCRIPTION:
# If your ebuild redefines src_unpack and uses EGO_SUM you need to call
# this function in src_unpack.
@@ -341,14 +340,11 @@ go-module_setup_proxy() {
# @FUNCTION: go-module_src_unpack
# @DESCRIPTION:
# If EGO_SUM is set, unpack the base tarball(s) and set up the
-# local go proxy. Also warn that this usage is deprecated.
+# local go proxy.
# - Otherwise, if EGO_VENDOR is set, bail out.
# - Otherwise do a normal unpack.
go-module_src_unpack() {
if [[ "${#EGO_SUM[@]}" -gt 0 ]]; then
- eqawarn "This ebuild uses EGO_SUM which is deprecated"
- eqawarn "Please migrate to a dependency tarball"
- eqawarn "This will become a fatal error in the future"
_go-module_src_unpack_gosum
elif [[ "${#EGO_VENDOR[@]}" -gt 0 ]]; then
eerror "${EBUILD} is using EGO_VENDOR which is no longer
supported"
@@ -359,7 +355,6 @@ go-module_src_unpack() {
}
# @FUNCTION: _go-module_src_unpack_gosum
-# @DEPRECATED: none
# @DESCRIPTION:
# Populate a GOPROXY directory hierarchy with distfiles from EGO_SUM and
# unpack the base distfiles.
@@ -405,7 +400,6 @@ _go-module_src_unpack_gosum() {
}
# @FUNCTION: _go-module_gosum_synthesize_files
-# @DEPRECATED: none
# @DESCRIPTION:
# Given a path & version, populate all Goproxy metadata files which aren't
# needed to be downloaded directly.
@@ -433,7 +427,6 @@ _go-module_gosum_synthesize_files() {
}
# @FUNCTION: _go-module_src_unpack_verify_gosum
-# @DEPRECATED: none
# @DESCRIPTION:
# Validate the Go modules declared by EGO_SUM are sufficient to cover building
# the package, without actually building it yet.
@@ -482,7 +475,6 @@ go-module_live_vendor() {
}
# @FUNCTION: _go-module_gomod_encode
-# @DEPRECATED: none
# @DESCRIPTION:
# Encode the name(path) of a Golang module in the format expected by Goproxy.
#
--
2.35.1
[gentoo-dev] Proposal to undeprecate EGO_SUM
Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM, where some voices where in agreement that EGO_SUM has its raison d'être, while there where no arguments in favor of eventually removing EGO_SUM, I hereby propose to undeprecate EGO_SUM. 1: https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa
[gentoo-dev] Last rites: dev-python/editdistance-s
# Michał Górny (2022-06-13) # Upstream has discontinued the fork. No revdeps. They recommend using # the original editdistance (not packaged on Gentoo) # or dev-python/ukkonen. # Removal on 2022-07-13. Bug #851678. dev-python/editdistance-s -- Best regards, Michał Górny
