[gentoo-dev] RFC: cargo.eclass changes and virtual/cargo retirement

[gentoo-dev] RFC: cargo.eclass changes and virtual/cargo retirement

[Georgy Yakovlev]

Bug: https://bugs.gentoo.org/695698

[gentoo-dev] [PATCH 1/3] cargo.eclass: do not use virtual/cargo anymore

[Georgy Yakovlev]

Bug: https://bugs.gentoo.org/695698
Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>
---
 eclass/cargo.eclass | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 44d11cdb838..dc031623067 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -14,14 +14,14 @@ _CARGO_ECLASS=1
 
 if [[ ${PV} == *9999* ]]; then
 	# we need at least this for cargo vendor subommand
-	CARGO_DEPEND=">=virtual/cargo-1.37.0"
+	RUST_DEPEND=">=virtual/rust-1.37.0"
 else
-	CARGO_DEPEND="virtual/cargo"
+	RUST_DEPEND="virtual/rust"
 fi
 
 case ${EAPI} in
-	6) DEPEND="${CARGO_DEPEND}";;
-	7) BDEPEND="${CARGO_DEPEND}";;
+	6) DEPEND="${RUST_DEPEND}";;
+	7) BDEPEND="${RUST_DEPEND}";;
 	*) die "EAPI=${EAPI:-0} is not supported" ;;
 esac
 
-- 
2.23.0

[gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[Georgy Yakovlev]

not used anymore

Closes: https://bugs.gentoo.org/695698
Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>
---
 virtual/cargo/cargo-1.34.2.ebuild | 17 -----------------
 virtual/cargo/cargo-1.35.0.ebuild | 17 -----------------
 virtual/cargo/cargo-1.36.0.ebuild | 17 -----------------
 virtual/cargo/cargo-1.37.0.ebuild | 17 -----------------
 virtual/cargo/cargo-1.38.0.ebuild | 17 -----------------
 virtual/cargo/metadata.xml        |  8 --------
 6 files changed, 93 deletions(-)
 delete mode 100644 virtual/cargo/cargo-1.34.2.ebuild
 delete mode 100644 virtual/cargo/cargo-1.35.0.ebuild
 delete mode 100644 virtual/cargo/cargo-1.36.0.ebuild
 delete mode 100644 virtual/cargo/cargo-1.37.0.ebuild
 delete mode 100644 virtual/cargo/cargo-1.38.0.ebuild
 delete mode 100644 virtual/cargo/metadata.xml

diff --git a/virtual/cargo/cargo-1.34.2.ebuild b/virtual/cargo/cargo-1.34.2.ebuild
deleted file mode 100644
index 032ae4f274f..00000000000
--- a/virtual/cargo/cargo-1.34.2.ebuild
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 1999-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=7
-
-DESCRIPTION="Package manager for Rust"
-HOMEPAGE=""
-SRC_URI=""
-
-LICENSE=""
-SLOT="0"
-KEYWORDS="amd64 ~arm64 ~ppc64 x86"
-
-RDEPEND="|| (
-			=dev-lang/rust-${PV}*
-			=dev-lang/rust-bin-${PV}*
-		)"
diff --git a/virtual/cargo/cargo-1.35.0.ebuild b/virtual/cargo/cargo-1.35.0.ebuild
deleted file mode 100644
index 2c015c4a0d9..00000000000
--- a/virtual/cargo/cargo-1.35.0.ebuild
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 1999-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=7
-
-DESCRIPTION="Package manager for Rust"
-HOMEPAGE=""
-SRC_URI=""
-
-LICENSE=""
-SLOT="0"
-KEYWORDS="~amd64 arm64 ~ppc64 ~x86"
-
-RDEPEND="|| (
-			=dev-lang/rust-${PV}*
-			=dev-lang/rust-bin-${PV}*
-		)"
diff --git a/virtual/cargo/cargo-1.36.0.ebuild b/virtual/cargo/cargo-1.36.0.ebuild
deleted file mode 100644
index 5e737019292..00000000000
--- a/virtual/cargo/cargo-1.36.0.ebuild
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 1999-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=7
-
-DESCRIPTION="Package manager for Rust"
-HOMEPAGE=""
-SRC_URI=""
-
-LICENSE=""
-SLOT="0"
-KEYWORDS="~amd64 ~arm64 ~ppc64 ~x86"
-
-RDEPEND="|| (
-			=dev-lang/rust-${PV}*
-			=dev-lang/rust-bin-${PV}*
-		)"
diff --git a/virtual/cargo/cargo-1.37.0.ebuild b/virtual/cargo/cargo-1.37.0.ebuild
deleted file mode 100644
index 631c2ccb793..00000000000
--- a/virtual/cargo/cargo-1.37.0.ebuild
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 1999-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=7
-
-DESCRIPTION="Package manager for Rust"
-HOMEPAGE=""
-SRC_URI=""
-
-LICENSE=""
-SLOT="0"
-KEYWORDS="amd64 arm64 ppc64 x86"
-
-RDEPEND="|| (
-			=dev-lang/rust-${PV}*
-			=dev-lang/rust-bin-${PV}*
-		)"
diff --git a/virtual/cargo/cargo-1.38.0.ebuild b/virtual/cargo/cargo-1.38.0.ebuild
deleted file mode 100644
index 5e737019292..00000000000
--- a/virtual/cargo/cargo-1.38.0.ebuild
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 1999-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=7
-
-DESCRIPTION="Package manager for Rust"
-HOMEPAGE=""
-SRC_URI=""
-
-LICENSE=""
-SLOT="0"
-KEYWORDS="~amd64 ~arm64 ~ppc64 ~x86"
-
-RDEPEND="|| (
-			=dev-lang/rust-${PV}*
-			=dev-lang/rust-bin-${PV}*
-		)"
diff --git a/virtual/cargo/metadata.xml b/virtual/cargo/metadata.xml
deleted file mode 100644
index 85cf4eb9205..00000000000
--- a/virtual/cargo/metadata.xml
+++ /dev/null
@@ -1,8 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
-<pkgmetadata>
-  <maintainer type="project">
-    <email>rust@gentoo.org</email>
-    <name>Rust Project</name>
-  </maintainer>
-</pkgmetadata>
-- 
2.23.0

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[Kent Fredric]

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

On Fri, 25 Oct 2019 15:03:39 -0700
Georgy Yakovlev <gyakovlev@gentoo.org> wrote:

> not used anymore
> 
> Closes: https://bugs.gentoo.org/695698
> Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>


Its likely this removal will cause the same kinds of problems faced by
the recent virtual/pam removal, just its more insidious, as the
dependency on the virtual is hidden away inside an eclass.

But this still means that anything users have already installed will
still depend on this, and without --changed-deps=y, it will break
portage's resolution of anything currently installed using this crate.

You can work-around this by -r1 bumping everything that used this
eclass .... but this just goes to show why there's policy against
eclasses changing the dependencies of their consumers without any
consumer involvement.

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

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[Michael Everitt]

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

On 26/10/19 04:59, Kent Fredric wrote:
> On Fri, 25 Oct 2019 15:03:39 -0700
> Georgy Yakovlev <gyakovlev@gentoo.org> wrote:
>
>> not used anymore
>>
>> Closes: https://bugs.gentoo.org/695698
>> Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>
>
> Its likely this removal will cause the same kinds of problems faced by
> the recent virtual/pam removal, just its more insidious, as the
> dependency on the virtual is hidden away inside an eclass.
>
> But this still means that anything users have already installed will
> still depend on this, and without --changed-deps=y, it will break
> portage's resolution of anything currently installed using this crate.
>
> You can work-around this by -r1 bumping everything that used this
> eclass .... but this just goes to show why there's policy against
> eclasses changing the dependencies of their consumers without any
> consumer involvement.
tl;dr - play with fire .. you're gonna get burned .. :]

Good luck with the core aim .. there is probably a slow-and-steady approach
that will win through ..


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

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[Francesco Riosa]

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

Il giorno sab 26 ott 2019 alle ore 06:24 Michael Everitt <gentoo@veremit.xyz>
ha scritto:

> On 26/10/19 04:59, Kent Fredric wrote:
> > On Fri, 25 Oct 2019 15:03:39 -0700
> > Georgy Yakovlev <gyakovlev@gentoo.org> wrote:
> >
> >> not used anymore
> >>
> >> Closes: https://bugs.gentoo.org/695698
> >> Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>
> >
> > Its likely this removal will cause the same kinds of problems faced by
> > the recent virtual/pam removal, just its more insidious, as the
> > dependency on the virtual is hidden away inside an eclass.
> >
> > But this still means that anything users have already installed will
> > still depend on this, and without --changed-deps=y, it will break
> > portage's resolution of anything currently installed using this crate.
> >
> > You can work-around this by -r1 bumping everything that used this
> > eclass .... but this just goes to show why there's policy against
> > eclasses changing the dependencies of their consumers without any
> > consumer involvement.
> tl;dr - play with fire .. you're gonna get burned .. :]
>
> Good luck with the core aim .. there is probably a slow-and-steady approach
> that will win through ..
>
> So basically the eclass should be bumped, with the old one deprecated?

[-- Attachment #2: Type: text/html, Size: 1948 bytes --]

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[Kent Fredric]

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

On Sat, 26 Oct 2019 08:34:50 +0200
Francesco Riosa <vivo75@gmail.com> wrote:

> So basically the eclass should be bumped, with the old one deprecated?  

I don't think rev-bumping the eclass is a useful way to fix this either.

It could work, but I suspect it just expands the problem slightly.

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

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[Dirkjan Ochtman]

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

On Sat, Oct 26, 2019, 05:59 Kent Fredric <kentnl@gentoo.org> wrote:

> On Fri, 25 Oct 2019 15:03:39 -0700
> Georgy Yakovlev <gyakovlev@gentoo.org> wrote:
>
> > not used anymore
> >
> > Closes: https://bugs.gentoo.org/695698
> > Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>
>
>
> Its likely this removal will cause the same kinds of problems faced by
> the recent virtual/pam removal, just its more insidious, as the
> dependency on the virtual is hidden away inside an eclass.
>
> But this still means that anything users have already installed will
> still depend on this, and without --changed-deps=y, it will break
> portage's resolution of anything currently installed using this crate.
>
> You can work-around this by -r1 bumping everything that used this
> eclass .... but this just goes to show why there's policy against
> eclasses changing the dependencies of their consumers without any
> consumer involvement.
>

In most if not all cases, this is just a build-time dependency. Do we
really have all these problems for build-time only dependencies?

>

[-- Attachment #2: Type: text/html, Size: 1890 bytes --]

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[Michał Górny]

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

On Sat, 2019-10-26 at 11:14 +0200, Dirkjan Ochtman wrote:
> On Sat, Oct 26, 2019, 05:59 Kent Fredric <kentnl@gentoo.org> wrote:
> 
> > On Fri, 25 Oct 2019 15:03:39 -0700
> > Georgy Yakovlev <gyakovlev@gentoo.org> wrote:
> > 
> > > not used anymore
> > > 
> > > Closes: https://bugs.gentoo.org/695698
> > > Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>
> > 
> > Its likely this removal will cause the same kinds of problems faced by
> > the recent virtual/pam removal, just its more insidious, as the
> > dependency on the virtual is hidden away inside an eclass.
> > 
> > But this still means that anything users have already installed will
> > still depend on this, and without --changed-deps=y, it will break
> > portage's resolution of anything currently installed using this crate.
> > 
> > You can work-around this by -r1 bumping everything that used this
> > eclass .... but this just goes to show why there's policy against
> > eclasses changing the dependencies of their consumers without any
> > consumer involvement.
> > 
> 
> In most if not all cases, this is just a build-time dependency. Do we
> really have all these problems for build-time only dependencies?
> 

Yes.  Because of --with-bdeps.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[William Hubbs]

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

On Sat, Oct 26, 2019 at 11:17:18AM +0200, Michał Górny wrote:
> On Sat, 2019-10-26 at 11:14 +0200, Dirkjan Ochtman wrote:
> > On Sat, Oct 26, 2019, 05:59 Kent Fredric <kentnl@gentoo.org> wrote:
> > 
> > > On Fri, 25 Oct 2019 15:03:39 -0700
> > > Georgy Yakovlev <gyakovlev@gentoo.org> wrote:
> > > 
> > > > not used anymore
> > > > 
> > > > Closes: https://bugs.gentoo.org/695698
> > > > Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>
> > > 
> > > Its likely this removal will cause the same kinds of problems faced by
> > > the recent virtual/pam removal, just its more insidious, as the
> > > dependency on the virtual is hidden away inside an eclass.
> > > 
> > > But this still means that anything users have already installed will
> > > still depend on this, and without --changed-deps=y, it will break
> > > portage's resolution of anything currently installed using this crate.
> > > 
> > > You can work-around this by -r1 bumping everything that used this
> > > eclass .... but this just goes to show why there's policy against
> > > eclasses changing the dependencies of their consumers without any
> > > consumer involvement.
> > > 
> > 
> > In most if not all cases, this is just a build-time dependency. Do we
> > really have all these problems for build-time only dependencies?
> > 
> 
> Yes.  Because of --with-bdeps.

I disagree, build-time dependencies can change in place because they
only affect the build. The problem with virtual/pam was that it was a
runtime dependency as well.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[Michael Everitt]

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

On 26/10/19 23:35, William Hubbs wrote:
> On Sat, Oct 26, 2019 at 11:17:18AM +0200, Michał Górny wrote:
>> On Sat, 2019-10-26 at 11:14 +0200, Dirkjan Ochtman wrote:
>>> On Sat, Oct 26, 2019, 05:59 Kent Fredric <kentnl@gentoo.org> wrote:
>>>
>>>> On Fri, 25 Oct 2019 15:03:39 -0700
>>>> Georgy Yakovlev <gyakovlev@gentoo.org> wrote:
>>>>
>>>>> not used anymore
>>>>>
>>>>> Closes: https://bugs.gentoo.org/695698
>>>>> Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>
>>>> Its likely this removal will cause the same kinds of problems faced by
>>>> the recent virtual/pam removal, just its more insidious, as the
>>>> dependency on the virtual is hidden away inside an eclass.
>>>>
>>>> But this still means that anything users have already installed will
>>>> still depend on this, and without --changed-deps=y, it will break
>>>> portage's resolution of anything currently installed using this crate.
>>>>
>>>> You can work-around this by -r1 bumping everything that used this
>>>> eclass .... but this just goes to show why there's policy against
>>>> eclasses changing the dependencies of their consumers without any
>>>> consumer involvement.
>>>>
>>> In most if not all cases, this is just a build-time dependency. Do we
>>> really have all these problems for build-time only dependencies?
>>>
>> Yes.  Because of --with-bdeps.
> I disagree, build-time dependencies can change in place because they
> only affect the build. The problem with virtual/pam was that it was a
> runtime dependency as well.
>
> William
The problem is that portage defaults to --with-bdeps=y, so any emerging of
packages now triggers anything that has a build-dep change, unless, as
previously stated, you exclude that case or change the defaults.



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

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[William Hubbs]

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

On Sun, Oct 27, 2019 at 12:14:59AM +0100, Michael Everitt wrote:
> On 26/10/19 23:35, William Hubbs wrote:
> > On Sat, Oct 26, 2019 at 11:17:18AM +0200, Michał Górny wrote:
> >> On Sat, 2019-10-26 at 11:14 +0200, Dirkjan Ochtman wrote:
> >>> On Sat, Oct 26, 2019, 05:59 Kent Fredric <kentnl@gentoo.org> wrote:
> >>>
> >>>> On Fri, 25 Oct 2019 15:03:39 -0700
> >>>> Georgy Yakovlev <gyakovlev@gentoo.org> wrote:
> >>>>
> >>>>> not used anymore
> >>>>>
> >>>>> Closes: https://bugs.gentoo.org/695698
> >>>>> Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>
> >>>> Its likely this removal will cause the same kinds of problems faced by
> >>>> the recent virtual/pam removal, just its more insidious, as the
> >>>> dependency on the virtual is hidden away inside an eclass.
> >>>>
> >>>> But this still means that anything users have already installed will
> >>>> still depend on this, and without --changed-deps=y, it will break
> >>>> portage's resolution of anything currently installed using this crate.
> >>>>
> >>>> You can work-around this by -r1 bumping everything that used this
> >>>> eclass .... but this just goes to show why there's policy against
> >>>> eclasses changing the dependencies of their consumers without any
> >>>> consumer involvement.
> >>>>
> >>> In most if not all cases, this is just a build-time dependency. Do we
> >>> really have all these problems for build-time only dependencies?
> >>>
> >> Yes.  Because of --with-bdeps.
> > I disagree, build-time dependencies can change in place because they
> > only affect the build. The problem with virtual/pam was that it was a
> > runtime dependency as well.
> >
> > William
> The problem is that portage defaults to --with-bdeps=y, so any emerging of
> packages now triggers anything that has a build-dep change, unless, as
> previously stated, you exclude that case or change the defaults.

Sure, but rebuild changes are  exactly what you would want. that's how
software written in go gets rebuilt for example, which is exactly what
you want when go is upgraded.

I agree that some rebuilds might be unnecessary, but if you don't like
compiling/building software Gentoo isn't for you.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[Michael Everitt]

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

On 27/10/19 00:55, William Hubbs wrote:
> On Sun, Oct 27, 2019 at 12:14:59AM +0100, Michael Everitt wrote:
>> On 26/10/19 23:35, William Hubbs wrote:
>>> On Sat, Oct 26, 2019 at 11:17:18AM +0200, Michał Górny wrote:
>>>> On Sat, 2019-10-26 at 11:14 +0200, Dirkjan Ochtman wrote:
>>>>> On Sat, Oct 26, 2019, 05:59 Kent Fredric <kentnl@gentoo.org> wrote:
>>>>>
>>>>>> On Fri, 25 Oct 2019 15:03:39 -0700
>>>>>> Georgy Yakovlev <gyakovlev@gentoo.org> wrote:
>>>>>>
>>>>>>> not used anymore
>>>>>>>
>>>>>>> Closes: https://bugs.gentoo.org/695698
>>>>>>> Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>
>>>>>> Its likely this removal will cause the same kinds of problems faced by
>>>>>> the recent virtual/pam removal, just its more insidious, as the
>>>>>> dependency on the virtual is hidden away inside an eclass.
>>>>>>
>>>>>> But this still means that anything users have already installed will
>>>>>> still depend on this, and without --changed-deps=y, it will break
>>>>>> portage's resolution of anything currently installed using this crate.
>>>>>>
>>>>>> You can work-around this by -r1 bumping everything that used this
>>>>>> eclass .... but this just goes to show why there's policy against
>>>>>> eclasses changing the dependencies of their consumers without any
>>>>>> consumer involvement.
>>>>>>
>>>>> In most if not all cases, this is just a build-time dependency. Do we
>>>>> really have all these problems for build-time only dependencies?
>>>>>
>>>> Yes.  Because of --with-bdeps.
>>> I disagree, build-time dependencies can change in place because they
>>> only affect the build. The problem with virtual/pam was that it was a
>>> runtime dependency as well.
>>>
>>> William
>> The problem is that portage defaults to --with-bdeps=y, so any emerging of
>> packages now triggers anything that has a build-dep change, unless, as
>> previously stated, you exclude that case or change the defaults.
> Sure, but rebuild changes are  exactly what you would want. that's how
> software written in go gets rebuilt for example, which is exactly what
> you want when go is upgraded.
>
> I agree that some rebuilds might be unnecessary, but if you don't like
> compiling/building software Gentoo isn't for you.
>
> William
>
There's a subtle difference between compiling for compiling's sake, and
compiling with good reason .. especially for those who don't have copious
quantities of free cpu resources at their disposal 24/7/365 ... just sayin' ...

And not everyone is using rust, go, java and systemd as their prime movers,
even if you are .. *shudders*


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

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[James Le Cuirot]

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

On Sun, 27 Oct 2019 01:42:48 +0000
Michael Everitt <gentoo@veremit.xyz> wrote:

> > I agree that some rebuilds might be unnecessary, but if you don't like
> > compiling/building software Gentoo isn't for you.
> >
> > William
> >  
> There's a subtle difference between compiling for compiling's sake, and
> compiling with good reason .. especially for those who don't have copious
> quantities of free cpu resources at their disposal 24/7/365 ... just sayin' ...
> 
> And not everyone is using rust, go, java and systemd as their prime movers,
> even if you are .. *shudders*

You do know that Rust code takes an age to compile, right? :P

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

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

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[Kent Fredric]

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

On Sat, 26 Oct 2019 18:55:11 -0500
William Hubbs <williamh@gentoo.org> wrote:

> Sure, but rebuild changes are  exactly what you would want. that's how
> software written in go gets rebuilt for example, which is exactly what
> you want when go is upgraded.
> 
> I agree that some rebuilds might be unnecessary, but if you don't like
> compiling/building software Gentoo isn't for you.
> 
> William

I suspect the problem might be moreso that --with-bdeps=y makes portage
prone to barf in this condition, not try recompiling.


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

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[William Hubbs]

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

On Sun, Oct 27, 2019 at 08:36:47PM +1300, Kent Fredric wrote:
> On Sat, 26 Oct 2019 18:55:11 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > Sure, but rebuild changes are  exactly what you would want. that's how
> > software written in go gets rebuilt for example, which is exactly what
> > you want when go is upgraded.
> > 
> > I agree that some rebuilds might be unnecessary, but if you don't like
> > compiling/building software Gentoo isn't for you.
> > 
> > William
> 
> I suspect the problem might be moreso that --with-bdeps=y makes portage
> prone to barf in this condition, not try recompiling.

No one has said there is a bug in portage in this situation, so I'd
rather not speculate until we have a bug report.

If a build dep of something changes, the correct response with
--with-bdeps=y is to rebuild everything that depends on the changed dep.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[Kent Fredric]

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

On Sun, 27 Oct 2019 12:05:02 -0500
William Hubbs <williamh@gentoo.org> wrote:

> If a build dep of something changes, the correct response with
> --with-bdeps=y is to rebuild everything that depends on the changed dep.

Unfortunately, my learned experience of portage is the "correct
response" is not something portage wants to do on its own without hand
holding.

/me has *only* had to write tools to get around this problem

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

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[William Hubbs]

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

On Mon, Oct 28, 2019 at 10:18:17AM +1300, Kent Fredric wrote:
> On Sun, 27 Oct 2019 12:05:02 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > If a build dep of something changes, the correct response with
> > --with-bdeps=y is to rebuild everything that depends on the changed dep.
> 
> Unfortunately, my learned experience of portage is the "correct
> response" is not something portage wants to do on its own without hand
> holding.

One thing I've noticed is you say things that portage might do without
giving any specifics.

Let's go ahead and do the change and file bugs against portage if there
are issues.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[Kent Fredric]

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

On Mon, 28 Oct 2019 10:34:40 -0500
William Hubbs <williamh@gentoo.org> wrote:

> Let's go ahead and do the change and file bugs against portage if there
> are issues.

Any time I find something that I'd imagine portage could fix, I file a bug.

But I already have so many open bugs for things portage does wrong that
have been languishing for years, that I have to revert to the "assume
portage just wont do the right thing" mentality.

I'm literally tired of filing these kind of bugs, and tired of having
to spoon-feed users in #gentoo with workarounds to get their systems
working.

Progress here on the problems I see seems *glacial*.

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

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[Michał Górny]

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

On Mon, 2019-10-28 at 10:34 -0500, William Hubbs wrote:
> On Mon, Oct 28, 2019 at 10:18:17AM +1300, Kent Fredric wrote:
> > On Sun, 27 Oct 2019 12:05:02 -0500
> > William Hubbs <williamh@gentoo.org> wrote:
> > 
> > > If a build dep of something changes, the correct response with
> > > --with-bdeps=y is to rebuild everything that depends on the changed dep.
> > 
> > Unfortunately, my learned experience of portage is the "correct
> > response" is not something portage wants to do on its own without hand
> > holding.
> 
> One thing I've noticed is you say things that portage might do without
> giving any specifics.
> 
> Let's go ahead and do the change and file bugs against portage if there
> are issues.
> 

The whole point of PMS/EAPI is that we can rely on package managers
behaving reasonably for any input.  Any package managers, in any
version.

You seem to be suggesting going in the opposite direction of making
newest Portage version handle bad input.  Using old version?  Tough
luck.  Using another package manager?  Tough luck.  Not fitting
in narrow space of solutions currently hacked around?  Tough luck.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[William Hubbs]

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

On Tue, Oct 29, 2019 at 05:48:14PM +0100, Michał Górny wrote:
> On Mon, 2019-10-28 at 10:34 -0500, William Hubbs wrote:
> > On Mon, Oct 28, 2019 at 10:18:17AM +1300, Kent Fredric wrote:
> > > On Sun, 27 Oct 2019 12:05:02 -0500
> > > William Hubbs <williamh@gentoo.org> wrote:
> > > 
> > > > If a build dep of something changes, the correct response with
> > > > --with-bdeps=y is to rebuild everything that depends on the changed dep.
> > > 
> > > Unfortunately, my learned experience of portage is the "correct
> > > response" is not something portage wants to do on its own without hand
> > > holding.
> > 
> > One thing I've noticed is you say things that portage might do without
> > giving any specifics.
> > 
> > Let's go ahead and do the change and file bugs against portage if there
> > are issues.
> > 
> 
> The whole point of PMS/EAPI is that we can rely on package managers
> behaving reasonably for any input.  Any package managers, in any
> version.
> 
> You seem to be suggesting going in the opposite direction of making
> newest Portage version handle bad input.  Using old version?  Tough
> luck.  Using another package manager?  Tough luck.  Not fitting
> in narrow space of solutions currently hacked around?  Tough luck.

No, I'm just saying this:

We don't know that there is a portage bug from what I'm reading in this thread. We are talking about possible bugs, but a possible bug isn't a bug. If there is an issue cite it otherwise move on.

--with-bdeps=y is the default for a good reason as far as I am aware.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[Kent Fredric]

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

On Tue, 29 Oct 2019 12:27:49 -0500
William Hubbs <williamh@gentoo.org> wrote:

> No, I'm just saying this:
> 
> We don't know that there is a portage bug from what I'm reading in this thread. We are talking about possible bugs, but a possible bug isn't a bug. If there is an issue cite it otherwise move on.
> 
> --with-bdeps=y is the default for a good reason as far as I am aware.
> 
> William

It only took a 3 days, but today, I'm helping a user who has a massive upgrade problem.

Among it, is this gem of a "conflict"


dev-python/setuptools:0

  (dev-python/setuptools-41.1.0:0/0::gentoo, ebuild scheduled for merge) pulled in by
    dev-python/setuptools[python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)] required by (dev-util/meson-0.51.2:0/0::gentoo, ebuild scheduled for merge)
                                                                                                                                                                                                                                                                                                                       
    dev-python/setuptools[python_targets_pypy(-)?,python_targets_pypy3(-)?,python_targets_python2_7(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)] required by (dev-python/certifi-2019.6.16:0/0::gentoo, ebuild scheduled for merge)
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

  (dev-python/setuptools-20.6.7:0/0::gentoo, installed) pulled in by
    dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (net-misc/youtube-dl-2016.09.19:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                                                   
    dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/jinja-2.8:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                                                                                                      
    dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/numpy-1.10.4:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                                            
    dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/certifi-2015.11.20:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                                                                                                               
    dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/pygments-2.1.1:0/0::gentoo, installed)
                                                                                                                                                                                                                                                                                                                                                                           
Why the hell is this happening?

Oh. Because portage is blocking upgrading something because they're
pulled into the graph by --with-bdeps=y

Passing --with-bdeps=n removes half of these conflicts ( but not all,
but thats probably some other problem, but I have no idea -what-
because portage refuses to tell me )

Portage just ain't bothered to try upgrading them properly, and ain't
smart enough to know that this is not an issue in the first place.

But I'd bet the remaining ones are "somebody did it wrong once upon a
time, but the user sill has installed copies of the packages where it
was done wrong"

But stupid portage is escallating *everything* to this stupid standard.

Which is garbage, because "upgrade setuptools" should in no way break
*anything* that is currently installed, let alone, something like x264
( which was the target problem at the time of trying to fix this )

And portage just *isnt* smart enough to fix this on its own.

Please spend more time helping users in #gentoo, you will see messes
like this on a *daily* basis.

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

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[William Hubbs]

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

On Wed, Oct 30, 2019 at 09:19:14PM +1300, Kent Fredric wrote:
> On Tue, 29 Oct 2019 12:27:49 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > No, I'm just saying this:
> > 
> > We don't know that there is a portage bug from what I'm reading in this thread. We are talking about possible bugs, but a possible bug isn't a bug. If there is an issue cite it otherwise move on.
> > 
> > --with-bdeps=y is the default for a good reason as far as I am aware.
> > 
> > William
> 
> It only took a 3 days, but today, I'm helping a user who has a massive upgrade problem.
> 
> Among it, is this gem of a "conflict"
> 
> 
> dev-python/setuptools:0
> 
>   (dev-python/setuptools-41.1.0:0/0::gentoo, ebuild scheduled for merge) pulled in by
>     dev-python/setuptools[python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)] required by (dev-util/meson-0.51.2:0/0::gentoo, ebuild scheduled for merge)
>                                                                                                                                                                                                                                                                                                                        
>     dev-python/setuptools[python_targets_pypy(-)?,python_targets_pypy3(-)?,python_targets_python2_7(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-)] required by (dev-python/certifi-2019.6.16:0/0::gentoo, ebuild scheduled for merge)
>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             
> 
>   (dev-python/setuptools-20.6.7:0/0::gentoo, installed) pulled in by
>     dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (net-misc/youtube-dl-2016.09.19:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                                                    
>     dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/jinja-2.8:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                                                                                                       
>     dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/numpy-1.10.4:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                                             
>     dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/certifi-2015.11.20:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                                                                                                                
>     dev-python/setuptools[python_targets_python2_7(-),python_targets_python3_4(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-)] required by (dev-python/pygments-2.1.1:0/0::gentoo, installed)
>                                                                                                                                                                                                                                                                                                                                                                            
> Why the hell is this happening?
> 
> Oh. Because portage is blocking upgrading something because they're
> pulled into the graph by --with-bdeps=y
> 
> Passing --with-bdeps=n removes half of these conflicts ( but not all,
> but thats probably some other problem, but I have no idea -what-
> because portage refuses to tell me )

You're right, I hate these kinds of error messages. I would go so far as
to say they are useless and the way this is handled should be cleaned
up.

I don't know portage internals, so I have no idea what the deal with
this is or how to fix it.

Did you report it to the portage team?

> Portage just ain't bothered to try upgrading them properly, and ain't
> smart enough to know that this is not an issue in the first place.
> 
> But I'd bet the remaining ones are "somebody did it wrong once upon a
> time, but the user sill has installed copies of the packages where it
> was done wrong"
> 
> But stupid portage is escallating *everything* to this stupid standard.
> 
> Which is garbage, because "upgrade setuptools" should in no way break
> *anything* that is currently installed, let alone, something like x264
> ( which was the target problem at the time of trying to fix this )
> 
> And portage just *isnt* smart enough to fix this on its own.
> 
> Please spend more time helping users in #gentoo, you will see messes
> like this on a *daily* basis.

I've noticed it gets messy very quickly if you wait a while to upgrade
your system also, so I would be curious how long the user waited to do
an upgrade?

Python is also more complex than most things because we allow multiple
versions.

There's no way to know whether removing virtual/rust will cause these
kinds of issues, so I'm still not convinced that we shouldn't remove it.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[William Hubbs]

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

On Wed, Oct 30, 2019 at 09:26:09AM -0500, William Hubbs wrote:
> There's no way to know whether removing virtual/rust will cause these
> kinds of issues, so I'm still not convinced that we shouldn't remove it.

Sorry, I meant virtual/cargo here.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[Kent Fredric]

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

On Wed, 30 Oct 2019 09:26:09 -0500
William Hubbs <williamh@gentoo.org> wrote:

> I don't know portage internals, so I have no idea what the deal with
> this is or how to fix it.
> 
> Did you report it to the portage team?

Report what?

1. Didn't have access to the box
2. No way to even conceive of producing enough information to replicate
it reliably enough that somebody could anticipate digging into the why.

> 
> I've noticed it gets messy very quickly if you wait a while to upgrade
> your system also, so I would be curious how long the user waited to do
> an upgrade?

And yeah, it was one of those cases of "bad sync length", the user in
question inherited the box from somebody else, and they were left to
pick up the pieces where the other person left off.

And one of the common things I see that frustrates me, is generally,
when you see these mountains of mess, somebody tries to argue its the
*users* fault for not updating more frequently.

But IMO, that's a rather distasteful buck-pass.

The duty of a linux vendor/linux vendor maintainer is to isolate users
from these kinds of problems, and we're clearly failing in this way.
> 
> Python is also more complex than most things because we allow multiple
> versions.
> 
> There's no way to know whether removing virtual/rust will cause these
> kinds of issues, so I'm still not convinced that we shouldn't remove
> it.

In light of the aforementioned axiom of "protect the user from messes",
I think it makes sense to approach this from the perspective of:

  If we imagine it could possibly cause a problem, until we prove it
  doesn't and can't, we must assume it _will_


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

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[William Hubbs]

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

On Thu, Oct 31, 2019 at 03:49:32AM +1300, Kent Fredric wrote:
> On Wed, 30 Oct 2019 09:26:09 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > I don't know portage internals, so I have no idea what the deal with
> > this is or how to fix it.
> > 
> > Did you report it to the portage team?
> 
> Report what?
> 
> 1. Didn't have access to the box
> 2. No way to even conceive of producing enough information to replicate
> it reliably enough that somebody could anticipate digging into the why.
> 
> > 
> > I've noticed it gets messy very quickly if you wait a while to upgrade
> > your system also, so I would be curious how long the user waited to do
> > an upgrade?
> 
> And yeah, it was one of those cases of "bad sync length", the user in
> question inherited the box from somebody else, and they were left to
> pick up the pieces where the other person left off.
> 
> And one of the common things I see that frustrates me, is generally,
> when you see these mountains of mess, somebody tries to argue its the
> *users* fault for not updating more frequently.
> 
> But IMO, that's a rather distasteful buck-pass.
> 
> The duty of a linux vendor/linux vendor maintainer is to isolate users
> from these kinds of problems, and we're clearly failing in this way.
> > 
> > Python is also more complex than most things because we allow multiple
> > versions.
> > 
> > There's no way to know whether removing virtual/rust will cause these
> > kinds of issues, so I'm still not convinced that we shouldn't remove
> > it.
> 
> In light of the aforementioned axiom of "protect the user from messes",
> I think it makes sense to approach this from the perspective of:
> 
>   If we imagine it could possibly cause a problem, until we prove it
>   doesn't and can't, we must assume it _will_

There are no ebuilds in the entire tree that directly depend on virtual/cargo;
only cargo.eclass lists it directly.

Because of that, There are two ways to get rid of virtual/cargo.

1. Apply the patches in this thread.

2. Create cargo-r1.eclass with the patches applied then move all consumers
in the tree to it and remove cargo.eclass.

The second option seems like overkill and would require a lot more work
than the first, but it could be done.

You are voicing concerns about either option, so is there a third
option other than removing the dependencies from cargo.eclass and
requiring the ebuilds to set their own dependencies?

If not, I would rather see you pick one of the two options above.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

[Kent Fredric]

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

On Wed, 30 Oct 2019 10:52:35 -0500
William Hubbs <williamh@gentoo.org> wrote:

> If not, I would rather see you pick one of the two options above.

-r1 bump all existing consumers of that eclass first? :)

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

[gentoo-dev] [PATCH 3/3] cargo.eclass: use verbose cargo invocation

[Georgy Yakovlev]

Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>
---
 eclass/cargo.eclass | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index dc031623067..940096ea230 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -115,8 +115,8 @@ cargo_live_src_unpack() {
 	mkdir -p "${S}" || die
 
 	pushd "${S}" > /dev/null || die
-	CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
-	CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
+	CARGO_HOME="${ECARGO_HOME}" cargo -vv fetch || die
+	CARGO_HOME="${ECARGO_HOME}" cargo -vv vendor "${ECARGO_VENDOR}" || die
 	popd > /dev/null || die
 
 	cargo_gen_config
@@ -146,7 +146,7 @@ cargo_src_compile() {
 
 	export CARGO_HOME="${ECARGO_HOME}"
 
-	cargo build -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
+	cargo -vv build -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
 		|| die "cargo build failed"
 }
 
@@ -156,7 +156,7 @@ cargo_src_compile() {
 cargo_src_install() {
 	debug-print-function ${FUNCNAME} "$@"
 
-	cargo install -j $(makeopts_jobs) --root="${D}/usr" $(usex debug --debug "") "$@" \
+	cargo -vv install -j $(makeopts_jobs) --root="${D}/usr" $(usex debug --debug "") "$@" \
 		|| die "cargo install failed"
 	rm -f "${D}/usr/.crates.toml"
 
@@ -169,7 +169,7 @@ cargo_src_install() {
 cargo_src_test() {
 	debug-print-function ${FUNCNAME} "$@"
 
-	cargo test -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
+	cargo -vv test -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
 		|| die "cargo test failed"
 }
 
-- 
2.23.0