Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python

2020-03-26 Thread Michał Górny
On Thu, 2020-03-26 at 22:12 +0100, Ulrich Mueller wrote:
> > > > > > On Thu, 26 Mar 2020, William Hubbs wrote:
> >  If there's a way inside an eclass to check that the ebuild inheriting
> > it is in ::gentoo, I will use it to die if the ebuild is in ::gentoo
> > and this variable is set.
> 
> Oh please, not this again. An ebuild or eclass is supposed to work the
> same everywhere, independent of the repo it is located in.
> 
> Why don't you simply copy the eclass to your overlay and do the changes
> there?
> 

They did, and then they complained that every few months they have to
update it.  See the big slander mail from William.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass

2020-03-26 Thread Michał Górny
On Thu, 2020-03-26 at 14:03 -0700, Patrick McLean wrote:
> This patch splits the definition of _PYTHON_ALL_IMPLS and
> _python_impl_supported to a separate eclass, this allows overlays
> to easily support a different set of python implementations than
> ::gentoo without having to fork the entire suite of eclasses.

NAK.  This increases the maintenance effort (even if it means having to
open yet another file) for *zero* gain to Gentoo users.  Your policy is
entirely broken by design and I'm against supporting it officially.

The existing number of eclasses is already causing confusion and added
maintenance effort, and it has strong justification in *a lot of shared
code*.

To say it bluntly: if you want to do stupid things, do them yourselves
and don't expect others to help.  You get paid for that.  We just waste
our time.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] musl doesn't provide execinfo.h

2020-03-26 Thread Jaco Kroon
Hi,

On 2020/03/27 03:25, Joshua Kinard wrote:
> On 3/23/2020 04:21, Jaco Kroon wrote:
>> Hi,
>>
>> https://bugs.gentoo.org/713668 relates.
>>
>>  * Searching for /usr/include/execinfo.h ...
>> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h)
>>
>> As I see I can either add an explicit depend on glibc which I'd prefer
>> not to.  Or someone from the musl team could possibly assist on how to
>> get the backtrace() set of calls on musl please?
>>
>> Alternatively I need to add a test and simply path debug.c to only
>> provide stub function for print_backtrace(FILE *fp) that just does
>> fprintf(fp, "No backtrace() available to print a backtrace.\n");
>>
>> Suggestions?
>>
>> Kind Regards,
>> Jaco
> Some quick searching on google, it looks like the cleanest fix for that bug
> is dahdi-tools needs to be patched to only include execinfo.h or only use
> backtrace() on glibc-based systems, and that patch then sent to the
> dahdi-tools upstream developers for inclusion in a future release.  That
> way, we're not dragging that patch around forever in the tree or in the musl
> overlay.

Thanks.  I'll see action accordingly.

>
> It also doesn't look like musl itself will ever implement execinfo.h or
> backtrace(), per this message in 2015 from the lead musl developer:
> https://www.openwall.com/lists/musl/2015/04/09/3
>
Implementing libunwind is overkill for my needs, I'll be happy to help
push things upstream if somebody else cares enough to implement.

Kind Regards,
Jaco




Re: [gentoo-dev] network sandbox challenge

2020-03-26 Thread Robin H. Johnson
On Fri, Mar 27, 2020 at 01:16:43AM +, Samuel Bernardo wrote:
> Dear all,
> 
> Fulfilling the linting of ebuild code style design for software projects
> that loads their dependencies during build, such as go based projects or
> npm as an example, could be very nasty.
> 
> Looking into source code of snapd or opennebula as two examples, I need
> to break network sandbox to get all dependencies for snapd go modules or
> opennebula sunstone npm code.
Have you looked at the EGO_SUM in go-module? This already covers ANY go
package that uses go.mod + go.sum, in a fully reproducible way that does
not break network sandbox.

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


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2]

2020-03-26 Thread Mike Gilbert
On Thu, Mar 26, 2020 at 7:19 PM Patrick McLean  wrote:
>
> This patch splits the definition of _PYTHON_ALL_IMPLS and
> _python_impl_supported to a separate eclass, this allows overlays
> to easily support a different set of python implementations than
> ::gentoo without having to fork the entire suite of eclasses.
>
> Changes from previous version (based on feedback on IRC):
> - add a guard variable to make sure it's being inherited
>   python-utils-r1.eclass

In the future, please generate patches using git-format-patch, and
mail them using git-send-email. That way we don't end up having to
open an attachment, and we can also review the commit message.



Re: [gentoo-dev] network sandbox challenge

2020-03-26 Thread Haelwenn (lanodan) Monnier
[2020-03-27 01:16:43+] Samuel Bernardo:
> 2) For snapd I need to load previously the remote repositories
> dependencies into a tar.gz that need to be stored in ebuild files. This
> is ugly, I know, but there is no distfiles trusted repository
> alternative where I can place them.
> As a workaround, I could create gitlab or github repository and use git
> lfs to upload the artifacts that need to be loaded (since I didn't know
> any free Artifactory or NexusOSS repositories community supported). Then
> use the provided url to download the files.

Couldn't the snapd_${PV}.vendor.tar.xz available in 
https://github.com/snapcore/snapd/releases 
work in your case to avoid downloading tarballs?
And probably consider using go-modules.eclass, which can also allow
packaging when there is no vendoring done by the upstream by just
cut(1)'ing the content of go.sum

And I'm not so sure why you want to apparently host a tarball?
Maybe you're not aware that SRC_URI accepts multiple tarballs? And 
btw you strongly should only use upstream URLs in it, they don't
need to be mirrored in distfiles.gentoo.org for the ebuild to work.



Re: [gentoo-dev] musl doesn't provide execinfo.h

2020-03-26 Thread Joshua Kinard
On 3/23/2020 04:21, Jaco Kroon wrote:
> Hi,
> 
> https://bugs.gentoo.org/713668 relates.
> 
>  * Searching for /usr/include/execinfo.h ...
> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h)
> 
> As I see I can either add an explicit depend on glibc which I'd prefer
> not to.  Or someone from the musl team could possibly assist on how to
> get the backtrace() set of calls on musl please?
> 
> Alternatively I need to add a test and simply path debug.c to only
> provide stub function for print_backtrace(FILE *fp) that just does
> fprintf(fp, "No backtrace() available to print a backtrace.\n");
> 
> Suggestions?
> 
> Kind Regards,
> Jaco

Some quick searching on google, it looks like the cleanest fix for that bug
is dahdi-tools needs to be patched to only include execinfo.h or only use
backtrace() on glibc-based systems, and that patch then sent to the
dahdi-tools upstream developers for inclusion in a future release.  That
way, we're not dragging that patch around forever in the tree or in the musl
overlay.

It also doesn't look like musl itself will ever implement execinfo.h or
backtrace(), per this message in 2015 from the lead musl developer:
https://www.openwall.com/lists/musl/2015/04/09/3

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



[gentoo-dev] network sandbox challenge

2020-03-26 Thread Samuel Bernardo
Dear all,

Fulfilling the linting of ebuild code style design for software projects
that loads their dependencies during build, such as go based projects or
npm as an example, could be very nasty.

Looking into source code of snapd or opennebula as two examples, I need
to break network sandbox to get all dependencies for snapd go modules or
opennebula sunstone npm code.

1) For opennebula I can use the full releases that brings already
generated sunstone code, with the penalty to loose some patches or
updates in the middle.

2) For snapd I need to load previously the remote repositories
dependencies into a tar.gz that need to be stored in ebuild files. This
is ugly, I know, but there is no distfiles trusted repository
alternative where I can place them.
As a workaround, I could create gitlab or github repository and use git
lfs to upload the artifacts that need to be loaded (since I didn't know
any free Artifactory or NexusOSS repositories community supported). Then
use the provided url to download the files.

What do think about this two cases and what are your suggestions?

Thanks,

Samuel




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH v2]

2020-03-26 Thread Patrick McLean
This patch splits the definition of _PYTHON_ALL_IMPLS and
_python_impl_supported to a separate eclass, this allows overlays
to easily support a different set of python implementations than
::gentoo without having to fork the entire suite of eclasses.

Changes from previous version (based on feedback on IRC):
- add a guard variable to make sure it's being inherited
  python-utils-r1.eclass
diff --git a/eclass/python-impls-r1.eclass b/eclass/python-impls-r1.eclass
new file mode 100644
index 000..622cb1ccef3
--- /dev/null
+++ b/eclass/python-impls-r1.eclass
@@ -0,0 +1,93 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: python-impls-r1.eclass
+# @MAINTAINER:
+# Python team 
+# @AUTHOR:
+# Author: Michał Górny 
+# Split to separate eclass by: Patrick McLean 
+# Based on work of: Krzysztof Pawlik 
+# @SUPPORTED_EAPIS: 5 6 7
+# @BLURB: Definitions of supported eclasses for python-utils-r1
+# @DESCRIPTION:
+# A helper eclass defining the supported python implementations for
+# the python-r1 suite of eclasses.
+#
+# This eclass is meant to be inherited by python-utils-r1, inheriting
+# it separately is very unlikely to be useful.
+#
+# For more information, please see the Python Guide:
+# https://dev.gentoo.org/~mgorny/python-guide/
+
+case "${EAPI:-0}" in
+	[0-4]) die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}" ;;
+	[5-7]) ;;
+	*) die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" ;;
+esac
+
+if [[ ${_PYTHON_ECLASS_INHERITED} ]]; then
+	die 'python-r1 suite eclasses can not be used with python.eclass.'
+
+elif [[ -z ${_PYTHON_ECLASS_CALLING} ]]; then
+	die 'python-impls-r1 can only be inherited from python-utils-r1'
+fi
+
+if [[ ! ${_PYTHON_IMPLS_R1} ]]; then
+
+# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
+# @INTERNAL
+# @DESCRIPTION:
+# All supported Python implementations, most preferred last.
+_PYTHON_ALL_IMPLS=(
+	pypy3
+	python2_7
+	python3_6 python3_7 python3_8
+)
+readonly _PYTHON_ALL_IMPLS
+
+# @ECLASS-VARIABLE: PYTHON_COMPAT_NO_STRICT
+# @INTERNAL
+# @DESCRIPTION:
+# Set to a non-empty value in order to make eclass tolerate (ignore)
+# unknown implementations in PYTHON_COMPAT.
+#
+# This is intended to be set by the user when using ebuilds that may
+# have unknown (newer) implementations in PYTHON_COMPAT. The assumption
+# is that the ebuilds are intended to be used within multiple contexts
+# which can involve revisions of this eclass that support a different
+# set of Python implementations.
+
+# @FUNCTION: _python_impl_supported
+# @USAGE: 
+# @INTERNAL
+# @DESCRIPTION:
+# Check whether the implementation  (PYTHON_COMPAT-form)
+# is still supported.
+#
+# Returns 0 if the implementation is valid and supported. If it is
+# unsupported, returns 1 -- and the caller should ignore the entry.
+# If it is invalid, dies with an appopriate error messages.
+_python_impl_supported() {
+	debug-print-function ${FUNCNAME} "${@}"
+
+	[[ ${#} -eq 1 ]] || die "${FUNCNAME}: takes exactly 1 argument (impl)."
+
+	local impl=${1}
+
+	# keep in sync with _PYTHON_ALL_IMPLS!
+	# (not using that list because inline patterns shall be faster)
+	case "${impl}" in
+		python2_7|python3_[678]|pypy3)
+			return 0
+			;;
+		jython2_7|pypy|pypy1_[89]|pypy2_0|python2_[56]|python3_[12345])
+			return 1
+			;;
+		*)
+			[[ ${PYTHON_COMPAT_NO_STRICT} ]] && return 1
+			die "Invalid implementation in PYTHON_COMPAT: ${impl}"
+	esac
+}
+_PYTHON_IMPLS_R1=1
+fi
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index aacee5ac35a..96e1bbbebe6 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -32,62 +32,9 @@ fi
 if [[ ! ${_PYTHON_UTILS_R1} ]]; then
 
 [[ ${EAPI} == 5 ]] && inherit eutils multilib
-inherit toolchain-funcs
-
-# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
-# @INTERNAL
-# @DESCRIPTION:
-# All supported Python implementations, most preferred last.
-_PYTHON_ALL_IMPLS=(
-	pypy3
-	python2_7
-	python3_6 python3_7 python3_8
-)
-readonly _PYTHON_ALL_IMPLS
-
-# @ECLASS-VARIABLE: PYTHON_COMPAT_NO_STRICT
-# @INTERNAL
-# @DESCRIPTION:
-# Set to a non-empty value in order to make eclass tolerate (ignore)
-# unknown implementations in PYTHON_COMPAT.
-#
-# This is intended to be set by the user when using ebuilds that may
-# have unknown (newer) implementations in PYTHON_COMPAT. The assumption
-# is that the ebuilds are intended to be used within multiple contexts
-# which can involve revisions of this eclass that support a different
-# set of Python implementations.
-
-# @FUNCTION: _python_impl_supported
-# @USAGE: 
-# @INTERNAL
-# @DESCRIPTION:
-# Check whether the implementation  (PYTHON_COMPAT-form)
-# is still supported.
-#
-# Returns 0 if the implementation is valid and supported. If it is
-# unsupported, returns 1 -- and the caller should ignore the entry.
-# If it is invalid, dies with an appopriate error messages.
-_python_impl_supported() {
-	debug-print-function ${FUNCNAME} "${@}"
-
-	[[ ${#} 

Re: [gentoo-dev] last rites: x11-terms/aterm, x11-terms/xvt

2020-03-26 Thread Jaco Kroon
Hi,

On 2020/03/26 23:34, Andreas K. Huettel wrote:

> # Andreas K. Hüttel  (2020-03-26)
> # Fail to build with glibc-2.30; no maintainer. Removal in 30days.
> # Bugs 691756, 691710
> x11-terms/aterm

I'll take this via proxy-maint.

Kind Regards,
Jaco




[gentoo-dev] last rites: x11-terms/aterm, x11-terms/xvt

2020-03-26 Thread Andreas K. Huettel
# Andreas K. Hüttel  (2020-03-26)
# Fail to build with glibc-2.30; no maintainer. Removal in 30days.
# Bugs 691756, 691710
x11-terms/aterm
x11-terms/xvt

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python

2020-03-26 Thread Ulrich Mueller
> On Thu, 26 Mar 2020, William Hubbs wrote:

>  If there's a way inside an eclass to check that the ebuild inheriting
> it is in ::gentoo, I will use it to die if the ebuild is in ::gentoo
> and this variable is set.

Oh please, not this again. An ebuild or eclass is supposed to work the
same everywhere, independent of the repo it is located in.

Why don't you simply copy the eclass to your overlay and do the changes
there?

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] [PATCH] Split python implementations definition to separate eclass

2020-03-26 Thread Patrick McLean
This patch splits the definition of _PYTHON_ALL_IMPLS and
_python_impl_supported to a separate eclass, this allows overlays
to easily support a different set of python implementations than
::gentoo without having to fork the entire suite of eclasses.
diff --git a/eclass/python-impls-r1.eclass b/eclass/python-impls-r1.eclass
new file mode 100644
index 000..0ae6e4e84a1
--- /dev/null
+++ b/eclass/python-impls-r1.eclass
@@ -0,0 +1,90 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: python-impls-r1.eclass
+# @MAINTAINER:
+# Python team 
+# @AUTHOR:
+# Author: Michał Górny 
+# Split to separate eclass by: Patrick McLean 
+# Based on work of: Krzysztof Pawlik 
+# @SUPPORTED_EAPIS: 5 6 7
+# @BLURB: Definitions of supported eclasses for python-utils-r1
+# @DESCRIPTION:
+# A helper eclass defining the supported python implementations for
+# the python-r1 suite of eclasses.
+#
+# This eclass is meant to be inherited by python-utils-r1, inheriting
+# it separately is very unlikely to be useful.
+#
+# For more information, please see the Python Guide:
+# https://dev.gentoo.org/~mgorny/python-guide/
+
+case "${EAPI:-0}" in
+	[0-4]) die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}" ;;
+	[5-7]) ;;
+	*) die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" ;;
+esac
+
+if [[ ${_PYTHON_ECLASS_INHERITED} ]]; then
+	die 'python-r1 suite eclasses can not be used with python.eclass.'
+fi
+
+if [[ ! ${_PYTHON_IMPLS_R1} ]]; then
+
+# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
+# @INTERNAL
+# @DESCRIPTION:
+# All supported Python implementations, most preferred last.
+_PYTHON_ALL_IMPLS=(
+	pypy3
+	python2_7
+	python3_6 python3_7 python3_8
+)
+readonly _PYTHON_ALL_IMPLS
+
+# @ECLASS-VARIABLE: PYTHON_COMPAT_NO_STRICT
+# @INTERNAL
+# @DESCRIPTION:
+# Set to a non-empty value in order to make eclass tolerate (ignore)
+# unknown implementations in PYTHON_COMPAT.
+#
+# This is intended to be set by the user when using ebuilds that may
+# have unknown (newer) implementations in PYTHON_COMPAT. The assumption
+# is that the ebuilds are intended to be used within multiple contexts
+# which can involve revisions of this eclass that support a different
+# set of Python implementations.
+
+# @FUNCTION: _python_impl_supported
+# @USAGE: 
+# @INTERNAL
+# @DESCRIPTION:
+# Check whether the implementation  (PYTHON_COMPAT-form)
+# is still supported.
+#
+# Returns 0 if the implementation is valid and supported. If it is
+# unsupported, returns 1 -- and the caller should ignore the entry.
+# If it is invalid, dies with an appopriate error messages.
+_python_impl_supported() {
+	debug-print-function ${FUNCNAME} "${@}"
+
+	[[ ${#} -eq 1 ]] || die "${FUNCNAME}: takes exactly 1 argument (impl)."
+
+	local impl=${1}
+
+	# keep in sync with _PYTHON_ALL_IMPLS!
+	# (not using that list because inline patterns shall be faster)
+	case "${impl}" in
+		python2_7|python3_[678]|pypy3)
+			return 0
+			;;
+		jython2_7|pypy|pypy1_[89]|pypy2_0|python2_[56]|python3_[12345])
+			return 1
+			;;
+		*)
+			[[ ${PYTHON_COMPAT_NO_STRICT} ]] && return 1
+			die "Invalid implementation in PYTHON_COMPAT: ${impl}"
+	esac
+}
+_PYTHON_IMPLS_R1=1
+fi
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index aacee5ac35a..28df410d5a1 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -32,62 +32,7 @@ fi
 if [[ ! ${_PYTHON_UTILS_R1} ]]; then
 
 [[ ${EAPI} == 5 ]] && inherit eutils multilib
-inherit toolchain-funcs
-
-# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
-# @INTERNAL
-# @DESCRIPTION:
-# All supported Python implementations, most preferred last.
-_PYTHON_ALL_IMPLS=(
-	pypy3
-	python2_7
-	python3_6 python3_7 python3_8
-)
-readonly _PYTHON_ALL_IMPLS
-
-# @ECLASS-VARIABLE: PYTHON_COMPAT_NO_STRICT
-# @INTERNAL
-# @DESCRIPTION:
-# Set to a non-empty value in order to make eclass tolerate (ignore)
-# unknown implementations in PYTHON_COMPAT.
-#
-# This is intended to be set by the user when using ebuilds that may
-# have unknown (newer) implementations in PYTHON_COMPAT. The assumption
-# is that the ebuilds are intended to be used within multiple contexts
-# which can involve revisions of this eclass that support a different
-# set of Python implementations.
-
-# @FUNCTION: _python_impl_supported
-# @USAGE: 
-# @INTERNAL
-# @DESCRIPTION:
-# Check whether the implementation  (PYTHON_COMPAT-form)
-# is still supported.
-#
-# Returns 0 if the implementation is valid and supported. If it is
-# unsupported, returns 1 -- and the caller should ignore the entry.
-# If it is invalid, dies with an appopriate error messages.
-_python_impl_supported() {
-	debug-print-function ${FUNCNAME} "${@}"
-
-	[[ ${#} -eq 1 ]] || die "${FUNCNAME}: takes exactly 1 argument (impl)."
-
-	local impl=${1}
-
-	# keep in sync with _PYTHON_ALL_IMPLS!
-	# (not using that list because inline patterns shall be faster)
-	case "${impl}" in
-		python2_7|python3_[678]|pypy3)
-			return 

Re: [gentoo-dev] Packages up for grabs: app-office/magicpoint, sys-apps/flashrom

2020-03-26 Thread Marek Szuba
On 2020-03-23 20:33, Jonas Stein wrote:

> sys-apps/flashrom

I'll take this one, I still use it from time to time.

-- 
MS



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python

2020-03-26 Thread Michał Górny
On Thu, 2020-03-26 at 13:47 -0700, Patrick McLean wrote:
> On Thu, 26 Mar 2020 21:11:11 +0100
> Michał Górny  wrote:
> 
> > On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote:
> > > There are situations in which downstream overlays need to have versions
> > > of python which Gentoo no longer supports in the tree.
> > > 
> > > Currently, the only way to do this is for the overlay author to fork
> > > python-utils-r1.eclass. This is highly undesirable since it creates a
> > > very significant maintenance burden for the overlay author.  
> > 
> > Is it preferable to create the maintenance burden on Gentoo developers
> > instead?  Is it fair that paid company developers shift the burden
> > on people who work on Gentoo in their free time, and already have their
> > plate full?
> 
> We have no intention of shifting maintenance burdens anywhere, we want
> to make minor changes to make it easier for us to keep up. It's the
> same as a Gentoo developer asking an upstream project to make minor
> changes to their build system to support DESTDIR or a sandbox fix.

No, that's the exact opposite of it.  Supporting DESTDIR is the correct
course of action that benefits a lot of people.  Adding hacks to make
a broken thing to pretend to work is the exact opposite of that.

> 
> > > The simplest way would be to apply the following patch.
> > > In this situation, all the overlay author
> > > would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable.  
> > 
> > ...which solves exactly zero problems because the eclass still doesn't
> > support the implementation in question.  The best it could do is sweep
> > part of the problem under the carpet.
> 
> We don't care if it *actually* supports it, the ebuilds in question
> aren't going to be installed on modern machines. We just want it to not
> blow up in the global scope.

Which makes literally zero sense.  If you don't want them to work,
remove them.  Don't ask ::gentoo to provide special support to keep
ebuilds that are 100% broken.


-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python

2020-03-26 Thread Patrick McLean
On Thu, 26 Mar 2020 21:11:11 +0100
Michał Górny  wrote:

> On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote:
> > There are situations in which downstream overlays need to have versions
> > of python which Gentoo no longer supports in the tree.
> > 
> > Currently, the only way to do this is for the overlay author to fork
> > python-utils-r1.eclass. This is highly undesirable since it creates a
> > very significant maintenance burden for the overlay author.  
> 
> Is it preferable to create the maintenance burden on Gentoo developers
> instead?  Is it fair that paid company developers shift the burden
> on people who work on Gentoo in their free time, and already have their
> plate full?

We have no intention of shifting maintenance burdens anywhere, we want
to make minor changes to make it easier for us to keep up. It's the
same as a Gentoo developer asking an upstream project to make minor
changes to their build system to support DESTDIR or a sandbox fix.

> 
> > The simplest way would be to apply the following patch.
> > In this situation, all the overlay author
> > would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable.  
> 
> ...which solves exactly zero problems because the eclass still doesn't
> support the implementation in question.  The best it could do is sweep
> part of the problem under the carpet.

We don't care if it *actually* supports it, the ebuilds in question
aren't going to be installed on modern machines. We just want it to not
blow up in the global scope.

> Even if it miraculously works right now at all, it will probably fail or
> misbehave randomly.  Any eclass change might break it.  Then one cheap
> hack will serve as an excuse to add one more, and another.\
> 
> > The other option would be to move _PYTHON_ALL_IMPLS and  the
> > implementation of _python_impl_supported to a separate eclass, e.g.
> > python-impls-r1.eclass. This eclass could be forked freely downstream
> > without worrying about the other python eclasses.  
> 
> Again, this doesn't solve the problem.  It just moves the problem
> elsewhere.  
> 

How does this not solve the problem? Overlays could trivially support
different implementations, without maintaining a lot of forks. We are
quite happy to do the work to split it out to a separate eclass.

> > Thoughts?  
> 
> I've already told you that if you want to fork, fork all eclasses.  Then
> you wouldn't have to worry about internal API going out of sync.
> 
> Or don't autoupdate ::gentoo when eclasses change.
> 




Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python

2020-03-26 Thread William Hubbs
On Thu, Mar 26, 2020 at 08:37:17PM +0100, David Seifert wrote:

*snip*

> How do you prevent some extra clever Gentoo developer from doing the following
> in ::gentoo
> 
>   dev-python/foo/foo-1.ebuild:
> 
>   # don't have the time to port this right now, patches welcome
>   PYTHON_COMPAT_ALLOW_EXTRA_IMPLS=( python3_4 )
>   PYTHON_COMPAT=( python3_4 )
>   inherit distutils-r1
 
 If there's a way inside an eclass to check that the ebuild inheriting
it is in ::gentoo, I will use it to die if the ebuild is in ::gentoo
and this variable is set.

> Furthermore, defining PYTHON_COMPAT_ALLOW_EXTRA_IMPLS is going to break 
> metadata
> invariance, causing tons of cache mis-hits. How do you prevent that?
> 
> In addition, this will very quickly cause whatever overlay this is being used 
> in
> to become invalid. Imagine I have dev-python/foo::gentoo that supports python
> 3.4 and 3.5 and have dev-python/bar::sony supporting 3.4 and 3.5 sitting in a
> hypothetical overlay, which depends on dev-python/foo::gentoo. Now we remove
> python 3.4 from ::gentoo in python-utils-r1, and one week later we remove
> python3.4 from dev-python/foo::gentoo's PYTHON_COMPAT. Now your dev-
> python/bar::sony in conjunction with PYTHON_COMPAT_ALLOW_EXTRA_IMPLS has an
> invalid depgraph. How do you wish to resolve this?

These are both overlay maintenance questions that wouldn't affect
::gentoo, but the answer to the first one is we regenerate the metadata
very often so it wouldn't be an issue, and the second one is  resolved
by grabbing packages and putting them in another overlay until we don't
need them.

> I feel like keeping up with ::gentoo is ultimately the better strategy than
> trying to add backdoors to eclasses because some overlays are somewhat behind.
 
I agree with you. However, sometimes in the real world it doesn't work
that way, or it can take longer to move than Gentoo.

If we can do something minimal to allow downstream overlays to do what
they need to do to catch up, I think we should, especially if someone
from downstream is offering to do the work.

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python

2020-03-26 Thread Robin H. Johnson
On Thu, Mar 26, 2020 at 09:11:11PM +0100, Michał Górny wrote:
> I've already told you that if you want to fork, fork all eclasses.  Then
> you wouldn't have to worry about internal API going out of sync.
> 
> Or don't autoupdate ::gentoo when eclasses change.
I also suggested something that is a corollary of this:
If you effectively freeze ::gentoo to different points for different
systems, then you ALSO need for generate frozen releases for your
overlay and backport critical changes to those releases.

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


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python

2020-03-26 Thread Michał Górny
On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote:
> There are situations in which downstream overlays need to have versions
> of python which Gentoo no longer supports in the tree.
> 
> Currently, the only way to do this is for the overlay author to fork
> python-utils-r1.eclass. This is highly undesirable since it creates a
> very significant maintenance burden for the overlay author.

Is it preferable to create the maintenance burden on Gentoo developers
instead?  Is it fair that paid company developers shift the burden
on people who work on Gentoo in their free time, and already have their
plate full?

> The simplest way would be to apply the following patch.
> In this situation, all the overlay author
> would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable.

...which solves exactly zero problems because the eclass still doesn't
support the implementation in question.  The best it could do is sweep
part of the problem under the carpet.

Even if it miraculously works right now at all, it will probably fail or
misbehave randomly.  Any eclass change might break it.  Then one cheap
hack will serve as an excuse to add one more, and another.

> The other option would be to move _PYTHON_ALL_IMPLS and  the
> implementation of _python_impl_supported to a separate eclass, e.g.
> python-impls-r1.eclass. This eclass could be forked freely downstream
> without worrying about the other python eclasses.

Again, this doesn't solve the problem.  It just moves the problem
elsewhere.  

> Thoughts?

I've already told you that if you want to fork, fork all eclasses.  Then
you wouldn't have to worry about internal API going out of sync.

Or don't autoupdate ::gentoo when eclasses change.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH 1/1] python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS

2020-03-26 Thread Michał Górny
On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote:
> This variable is meant to be set in downstream overlays when they need python
> implementations other than the ones we support in the tree.
> It should be a space-separated list of extra implementations.
> 
> Signed-off-by: William Hubbs 
> ---
>  eclass/python-utils-r1.eclass | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> index aacee5ac35a..4370c7a825f 100644
> --- a/eclass/python-utils-r1.eclass
> +++ b/eclass/python-utils-r1.eclass
> @@ -43,6 +43,8 @@ _PYTHON_ALL_IMPLS=(
>   python2_7
>   python3_6 python3_7 python3_8
>  )
> +[[ -n ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS[*]} ]] &&
> + _PYTHON_ALL_IMPLS+=( ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS} )
>  readonly _PYTHON_ALL_IMPLS
>  
>  # @ECLASS-VARIABLE: PYTHON_COMPAT_NO_STRICT

How is this supposed to work, exactly?  If you scroll to the next
function you'd realize that after this change this 'extra
implementation' will most likely be simultaneously considered supported
and unsupported.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH 1/1] python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS

2020-03-26 Thread William Hubbs
On Thu, Mar 26, 2020 at 03:37:48PM -0400, Mike Gilbert wrote:
> On Thu, Mar 26, 2020 at 3:13 PM William Hubbs  wrote:
> >
> > This variable is meant to be set in downstream overlays when they need 
> > python
> > implementations other than the ones we support in the tree.
> > It should be a space-separated list of extra implementations.
> 
> This new variable should be documented in the eclass, along with a
> note that its use is unsupported for general use.
>
> Do you intend this variable to be set in profiles or make.conf? In
> either case, I don't think you can use bash arrays. Also, you're
> mixing scalar and array variable syntax in your patch.

Sure, I can do that. I'll fix up the syntax and add the documentation.

Thanks,

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH 1/1] python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS

2020-03-26 Thread Mike Gilbert
On Thu, Mar 26, 2020 at 3:13 PM William Hubbs  wrote:
>
> This variable is meant to be set in downstream overlays when they need python
> implementations other than the ones we support in the tree.
> It should be a space-separated list of extra implementations.

This new variable should be documented in the eclass, along with a
note that its use is unsupported for general use.

Do you intend this variable to be set in profiles or make.conf? In
either case, I don't think you can use bash arrays. Also, you're
mixing scalar and array variable syntax in your patch.



Re: [gentoo-dev] [PATCH 0/1] allow extra implementations of python

2020-03-26 Thread David Seifert
On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote:
> There are situations in which downstream overlays need to have versions
> of python which Gentoo no longer supports in the tree.
> 
> Currently, the only way to do this is for the overlay author to fork
> python-utils-r1.eclass. This is highly undesirable since it creates a
> very significant maintenance burden for the overlay author.
> 
> There are a couple of things we can do upstream to make this easier, and
> I think we should do one of them.
> 
> The simplest way would be to apply the following patch.
> In this situation, all the overlay author
> would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable.
> 
> The other option would be to move _PYTHON_ALL_IMPLS and  the
> implementation of _python_impl_supported to a separate eclass, e.g.
> python-impls-r1.eclass. This eclass could be forked freely downstream
> without worrying about the other python eclasses.
> I will volunteer to do the legwork for this option if we do not like the
> first one.
> 
> I would advocate the first option however since no one has to fork
> anything.
> 
> Thoughts?
> 
> William
> 
> William Hubbs (1):
>   python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS
> 
>  eclass/python-utils-r1.eclass | 2 ++
>  1 file changed, 2 insertions(+)
> 

How do you prevent some extra clever Gentoo developer from doing the following
in ::gentoo

  dev-python/foo/foo-1.ebuild:

  # don't have the time to port this right now, patches welcome
  PYTHON_COMPAT_ALLOW_EXTRA_IMPLS=( python3_4 )
  PYTHON_COMPAT=( python3_4 )
  inherit distutils-r1

Furthermore, defining PYTHON_COMPAT_ALLOW_EXTRA_IMPLS is going to break metadata
invariance, causing tons of cache mis-hits. How do you prevent that?

In addition, this will very quickly cause whatever overlay this is being used in
to become invalid. Imagine I have dev-python/foo::gentoo that supports python
3.4 and 3.5 and have dev-python/bar::sony supporting 3.4 and 3.5 sitting in a
hypothetical overlay, which depends on dev-python/foo::gentoo. Now we remove
python 3.4 from ::gentoo in python-utils-r1, and one week later we remove
python3.4 from dev-python/foo::gentoo's PYTHON_COMPAT. Now your dev-
python/bar::sony in conjunction with PYTHON_COMPAT_ALLOW_EXTRA_IMPLS has an
invalid depgraph. How do you wish to resolve this?

I feel like keeping up with ::gentoo is ultimately the better strategy than
trying to add backdoors to eclasses because some overlays are somewhat behind.

Regards
David




Re: [gentoo-dev] [PATCH 1/1] python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS

2020-03-26 Thread Rolf Eike Beer
> +[[ -n ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS[*]} ]] &&

Without string check:

[[ ${#PYTHON_COMPAT_ALLOW_EXTRA_IMPLS[@]} -gt 0 ]]

> + _PYTHON_ALL_IMPLS+=( ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS} )
>  readonly _PYTHON_ALL_IMPLS

Once array, always array:

_PYTHON_ALL_IMPLS+=( ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS[@]} )


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] [PATCH 1/1] python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS

2020-03-26 Thread William Hubbs
This variable is meant to be set in downstream overlays when they need python
implementations other than the ones we support in the tree.
It should be a space-separated list of extra implementations.

Signed-off-by: William Hubbs 
---
 eclass/python-utils-r1.eclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index aacee5ac35a..4370c7a825f 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -43,6 +43,8 @@ _PYTHON_ALL_IMPLS=(
python2_7
python3_6 python3_7 python3_8
 )
+[[ -n ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS[*]} ]] &&
+   _PYTHON_ALL_IMPLS+=( ${PYTHON_COMPAT_ALLOW_EXTRA_IMPLS} )
 readonly _PYTHON_ALL_IMPLS
 
 # @ECLASS-VARIABLE: PYTHON_COMPAT_NO_STRICT
-- 
2.24.1




[gentoo-dev] [PATCH 0/1] allow extra implementations of python

2020-03-26 Thread William Hubbs
There are situations in which downstream overlays need to have versions
of python which Gentoo no longer supports in the tree.

Currently, the only way to do this is for the overlay author to fork
python-utils-r1.eclass. This is highly undesirable since it creates a
very significant maintenance burden for the overlay author.

There are a couple of things we can do upstream to make this easier, and
I think we should do one of them.

The simplest way would be to apply the following patch.
In this situation, all the overlay author
would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable.

The other option would be to move _PYTHON_ALL_IMPLS and  the
implementation of _python_impl_supported to a separate eclass, e.g.
python-impls-r1.eclass. This eclass could be forked freely downstream
without worrying about the other python eclasses.
I will volunteer to do the legwork for this option if we do not like the
first one.

I would advocate the first option however since no one has to fork
anything.

Thoughts?

William

William Hubbs (1):
  python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS

 eclass/python-utils-r1.eclass | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.24.1




[gentoo-dev] Re: autotools

2020-03-26 Thread Samuel Bernardo
Thank you Michal and Haelwenn for your advises.

I'm taking as reference the documentation about functions syntax in
devmanual[1] (very useful for a quickly review).

In the source code where autoreconf is being called I found a
configure.ac and Makefile.am.

Looking into autogen.sh[2] script prvided by the maintainer I confirm
that he runs the following commands:

- autoreconf -i -f

- for each supported distribution defines variable extra_opts

- "${SRC_DIR}/configure" --enable-maintainer-mode --prefix=/usr
$extra_opts "$@"

So it seems that the best approach would be the way you suggested in
your example Haelwenn.

[1] https://devmanual.gentoo.org/eclass-reference/ebuild/index.html

[2] https://github.com/snapcore/snapd/blob/master/cmd/autogen.sh




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] autotools

2020-03-26 Thread Haelwenn (lanodan) Monnier
[2020-03-26 17:47:35+] Samuel Bernardo:
> I send this email to ask you for your help for the better approach to
> translate the following autoreconf command to an ebuild:
> 
> > |autoreconf -i -f ./configure \ --prefix=/usr \
> > --libexecdir=/usr/lib/snapd \
> > --with-snap-mount-dir=/var/lib/snapd/snap \ --enable-apparmor \
> > --enable-nvidia-biarch \ --enable-merged-usr|
> I realise that eautoreconf from autotools.eclass doesn't accept any
> parameters, so how would you advise me to reproduce it inside an ebuild
> using the available functions and eclasses?
> 
> My goal is to create an ebuild from latest snapd pkgbuild:
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=snapd

Not sure if this would work out-of-the-box but this is how it is usually done:

src_prepare() {
default
eautoreconf
}

src_configure() {
econf \
--with-snap-mount-dir=/var/lib/snapd/snap \
--enable-nvidia-biarch \
--enable-merged-usr \
$(use_enable apparmor)
}

But as AUR has basically no quality requirement also consider that maybe it 
doesn't need eautoreconf at all, which can be nice to avoid.




[gentoo-dev] Re: autotools

2020-03-26 Thread Michal Prívozník
On 26. 3. 2020 18:47, Samuel Bernardo wrote:
> Dear all,
> 
> I send this email to ask you for your help for the better approach to
> translate the following autoreconf command to an ebuild:
> 
>> |autoreconf -i -f ./configure \ --prefix=/usr \
>> --libexecdir=/usr/lib/snapd \
>> --with-snap-mount-dir=/var/lib/snapd/snap \ --enable-apparmor \
>> --enable-nvidia-biarch \ --enable-merged-usr|
> I realise that eautoreconf from autotools.eclass doesn't accept any
> parameters, so how would you advise me to reproduce it inside an ebuild
> using the available functions and eclasses?
> 
> My goal is to create an ebuild from latest snapd pkgbuild:
> 
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=snapd
> 
> Thank you,
> 
> Samuel
> 

I guess you are not really after autoreconf arguments rather than
./configure ones. You want to focus on src_configure() in the ebuild. I
suggest starting here:


https://devmanual.gentoo.org/ebuild-writing/functions/src_configure/configuring/index.html

and there are plenty of examples existing in the portage. You will need
to define USE flags for your ebuild though so that users can
enable/disable parts of functionality.

Happy hacking!

Michal




[gentoo-dev] autotools

2020-03-26 Thread Samuel Bernardo
Dear all,

I send this email to ask you for your help for the better approach to
translate the following autoreconf command to an ebuild:

> |autoreconf -i -f ./configure \ --prefix=/usr \
> --libexecdir=/usr/lib/snapd \
> --with-snap-mount-dir=/var/lib/snapd/snap \ --enable-apparmor \
> --enable-nvidia-biarch \ --enable-merged-usr|
I realise that eautoreconf from autotools.eclass doesn't accept any
parameters, so how would you advise me to reproduce it inside an ebuild
using the available functions and eclasses?

My goal is to create an ebuild from latest snapd pkgbuild:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=snapd

Thank you,

Samuel



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: dev-python/aiohttp-cors, net-misc/gns3*

2020-03-26 Thread Michał Górny
# Michał Górny  (2020-03-26)
# dev-python/aiohttp-cors is dead upstream and does not support
# Python 3.7 and newer.
#
# net-misc/gns3-* are effectively unmaintained and stuck with py3.6.
# gns3-server is the only revdep of aiohttp-cors, as well as the only
# blocker for removal of old dev-python/{aiohttp,async_timeout}
# (bug #714840).  Some of those issues might be fixed by a version bump
# that's pending for a long time (bug #688016) but not aiohttp-cors dep.
#
# Removal in 30 days.  Bug #712964.
dev-python/aiohttp-cors
net-misc/gns3-converter
net-misc/gns3-gui
net-misc/gns3-server

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-portage-dev] precisions on installed packages' dependencies

2020-03-26 Thread Alec Warner
On Tue, Mar 24, 2020 at 11:31 AM  wrote:

>
> - Zac Medico  a écrit :
>
> > > The goal of my tool is to have correct manipulation of package
> dependencies, and in particular here, I focus on the packages that are
> installed but not in the portage tree/a local overlay anymore (the problem
> does not occur for other packages).
> > > It seems that installed packages do not store which are the actual cpv
> they depend on. Correct?
> >
> > Right, because unfortunately that's something that changes over time.
> >
> > Also, we may not be able to pin it down at any given moment if we have
> > inconsistent || preferences as described here:
> >
> >
> https://archives.gentoo.org/gentoo-dev/message/550d3859dea6d0fb0b39064628992634
>
> Hmm, I think I see what you mean.
> Storing the cpvs that was used during solving the package's dependencies
> would be too restrictive, since two different packages could provide the
> exact same functionalities/libraries.
> And so, during a system update, only looking at the cpv dependencies would
> trigger useless recompilation of the packages that depend on the updated
> packages.
> Correct?
>
> Btw, my tool's solver does not have the problem discussed in the thread
> you're mentioning: atom order in lists has no influence in my solver.
> Would fixing the inconsistent || preferences make storing cpvs for
> installed packages more realistic?
>
>
> > > Also, I wanted to use the ebuild tool to install/uninstall package,
> which is not possible with this solution apparently.
> >
> > Why not? Would the preserve-libs feature solve your problem?
>
> ... I'm sorry, I wasn't aware of this feature.
> It would definitively solve the issue (except, as described in the bug
> 459038, when external tools remove libs).
>
> This discussion is very interesting!
> If I take this double layer of dependencies, I have to check how this
> influences the theory underlying my tool.
>
> However, I still doubt that only storing the soname dependencies is enough.
> Consider package A (that cannot be recompiled) that depends on package B
> which provides lib L.so.
> B is recompiled with different use flags, which put different
> functionalities in L.so.
> The dependencies of A are still satisfied (B is installed, L.so is
> available), but since the content of L.so changed, A cannot execute anymore.
> Hypothetically, can this scenario occur?
> Can this scenario occur in practice?
> Is there a way in emerge/portage to avoid it?
>

>
> > Well, there are a lot of upgrades that can't be performed without
> > temporarily breaking something, so the "forbid broken dependencies" idea
> > doesn't sound feasible to me.
>
> Could you tell me about several instances of such needed dependency
> breakage?
> You have far more experience than me on this, and it would be nice for me
> to know what I'm up against.
>

A lot of this has to do with the specifics of how package managers manage
system state, as well as various quirks of subsets of the tree. For
example, a perl upgrade (X->Y) will often break perl modules who expect
perl-X, but get perl-Y. So one fix is to try to keep perl-X installed (so
we SLOT perl and have N perls installed.) Then you need to decide which
version of perl to build things against (X or Y, or both?) We took this
tactic in the python ecosystem; but perl is not slotted in Gentoo, and so
upgrading perl breaks all perl modules. There is a tool
(gentoo-perl-cleaner) that will walk the deptree and fix all of these
broken packages that you run after an upgrade.

I'm not sure it's strictly avoidable. You could build perl-Y, then rebuild
all perl-modules against perl-Y, then merge the entire result to the
livefs. This will reduce the breakage time but likely not eliminate it;
plus it seems hard to implement in practice without modern filesystem tools
(overlayfs, btrfs, zfs or similar tech to make it atomic.) It also doesn't
account for executing code. What happens to perl-X code that is executing
when you unmerge perl-X? The short answer is that code might break and
'proper' management means you should restart services after an upgrade
(something Gentoo doesn't typically do; but is common in Debian for
example.)

-A


> Many thanks!
> Michael
>
>


Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses

2020-03-26 Thread William Hubbs
On Wed, Mar 25, 2020 at 10:29:23AM +0100, Michał Górny wrote:
> William,
> 
> So many things are wrong with this e-mail, I'm not even sure where to
> start.  In my opinion, this mail shouldn't have ever happened.  While
> I believe you had a good intent, this does not justify sending such
> mails without verifying your claims first.

I apologize for being vague in my initial email about what
my claims were. It would have been better to link the changes up front
instead of later in the thread and give more information about what was
broken, and I will do this next time around.

Also, I do agree that cc'ing QA and the council was overkill for an
rfc message.

I hope we can move on from this thread. Let me know what you think.

From my pov, the incident that prompted this highlights some concerns about
our eclass patch handling process, so expect a separate thread from me
soon about this process.

Thanks,

William



signature.asc
Description: Digital signature