RFC: cargo.eclass changes and virtual/cargo retirement

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

RFC: cargo.eclass changes and virtual/cargo retirement

Georgy Yakovlev-2
Reply | Threaded
Open this post in threaded view
|

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

Georgy Yakovlev-2
Bug: https://bugs.gentoo.org/695698
Signed-off-by: Georgy Yakovlev <[hidden email]>
---
 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


Reply | Threaded
Open this post in threaded view
|

[PATCH 2/3] virtual/cargo: drop virtual

Georgy Yakovlev-2
In reply to this post by Georgy Yakovlev-2
not used anymore

Closes: https://bugs.gentoo.org/695698
Signed-off-by: Georgy Yakovlev <[hidden email]>
---
 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>[hidden email]</email>
-    <name>Rust Project</name>
-  </maintainer>
-</pkgmetadata>
--
2.23.0


Reply | Threaded
Open this post in threaded view
|

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

Georgy Yakovlev-2
In reply to this post by Georgy Yakovlev-2
Signed-off-by: Georgy Yakovlev <[hidden email]>
---
 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


Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/3] virtual/cargo: drop virtual

Kent Fredric-2
In reply to this post by Georgy Yakovlev-2
On Fri, 25 Oct 2019 15:03:39 -0700
Georgy Yakovlev <[hidden email]> wrote:

> not used anymore
>
> Closes: https://bugs.gentoo.org/695698
> Signed-off-by: Georgy Yakovlev <[hidden email]>


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.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/3] virtual/cargo: drop virtual

Michael 'veremitz' Everitt
On 26/10/19 04:59, Kent Fredric wrote:

> On Fri, 25 Oct 2019 15:03:39 -0700
> Georgy Yakovlev <[hidden email]> wrote:
>
>> not used anymore
>>
>> Closes: https://bugs.gentoo.org/695698
>> Signed-off-by: Georgy Yakovlev <[hidden email]>
>
> 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 ..


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/3] virtual/cargo: drop virtual

Francesco Riosa-3


Il giorno sab 26 ott 2019 alle ore 06:24 Michael Everitt <[hidden email]> ha scritto:
On 26/10/19 04:59, Kent Fredric wrote:
> On Fri, 25 Oct 2019 15:03:39 -0700
> Georgy Yakovlev <[hidden email]> wrote:
>
>> not used anymore
>>
>> Closes: https://bugs.gentoo.org/695698
>> Signed-off-by: Georgy Yakovlev <[hidden email]>
>
> 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?
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/3] virtual/cargo: drop virtual

Kent Fredric-2
On Sat, 26 Oct 2019 08:34:50 +0200
Francesco Riosa <[hidden email]> 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.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/3] virtual/cargo: drop virtual

Dirkjan Ochtman-3
In reply to this post by Kent Fredric-2
On Sat, Oct 26, 2019, 05:59 Kent Fredric <[hidden email]> wrote:
On Fri, 25 Oct 2019 15:03:39 -0700
Georgy Yakovlev <[hidden email]> wrote:

> not used anymore
>
> Closes: https://bugs.gentoo.org/695698
> Signed-off-by: Georgy Yakovlev <[hidden email]>


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? 
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/3] virtual/cargo: drop virtual

Michał Górny-5
On Sat, 2019-10-26 at 11:14 +0200, Dirkjan Ochtman wrote:

> On Sat, Oct 26, 2019, 05:59 Kent Fredric <[hidden email]> wrote:
>
> > On Fri, 25 Oct 2019 15:03:39 -0700
> > Georgy Yakovlev <[hidden email]> wrote:
> >
> > > not used anymore
> > >
> > > Closes: https://bugs.gentoo.org/695698
> > > Signed-off-by: Georgy Yakovlev <[hidden email]>
> >
> > 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


signature.asc (631 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/3] virtual/cargo: drop virtual

William Hubbs
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 <[hidden email]> wrote:
> >
> > > On Fri, 25 Oct 2019 15:03:39 -0700
> > > Georgy Yakovlev <[hidden email]> wrote:
> > >
> > > > not used anymore
> > > >
> > > > Closes: https://bugs.gentoo.org/695698
> > > > Signed-off-by: Georgy Yakovlev <[hidden email]>
> > >
> > > 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

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[PATCH 2/3] virtual/cargo: drop virtual

Michael 'veremitz' Everitt
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 <[hidden email]> wrote:
>>>
>>>> On Fri, 25 Oct 2019 15:03:39 -0700
>>>> Georgy Yakovlev <[hidden email]> wrote:
>>>>
>>>>> not used anymore
>>>>>
>>>>> Closes: https://bugs.gentoo.org/695698
>>>>> Signed-off-by: Georgy Yakovlev <[hidden email]>
>>>> 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.



signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/3] virtual/cargo: drop virtual

William Hubbs
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 <[hidden email]> wrote:
> >>>
> >>>> On Fri, 25 Oct 2019 15:03:39 -0700
> >>>> Georgy Yakovlev <[hidden email]> wrote:
> >>>>
> >>>>> not used anymore
> >>>>>
> >>>>> Closes: https://bugs.gentoo.org/695698
> >>>>> Signed-off-by: Georgy Yakovlev <[hidden email]>
> >>>> 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


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/3] virtual/cargo: drop virtual

Michael 'veremitz' Everitt
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 <[hidden email]> wrote:
>>>>>
>>>>>> On Fri, 25 Oct 2019 15:03:39 -0700
>>>>>> Georgy Yakovlev <[hidden email]> wrote:
>>>>>>
>>>>>>> not used anymore
>>>>>>>
>>>>>>> Closes: https://bugs.gentoo.org/695698
>>>>>>> Signed-off-by: Georgy Yakovlev <[hidden email]>
>>>>>> 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*


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/3] virtual/cargo: drop virtual

Kent Fredric-2
In reply to this post by William Hubbs
On Sat, 26 Oct 2019 18:55:11 -0500
William Hubbs <[hidden email]> 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.


attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/3] virtual/cargo: drop virtual

James Le Cuirot
In reply to this post by Michael 'veremitz' Everitt
On Sun, 27 Oct 2019 01:42:48 +0000
Michael Everitt <[hidden email]> 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

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/3] virtual/cargo: drop virtual

William Hubbs
In reply to this post by Kent Fredric-2
On Sun, Oct 27, 2019 at 08:36:47PM +1300, Kent Fredric wrote:

> On Sat, 26 Oct 2019 18:55:11 -0500
> William Hubbs <[hidden email]> 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


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/3] virtual/cargo: drop virtual

Kent Fredric-2
On Sun, 27 Oct 2019 12:05:02 -0500
William Hubbs <[hidden email]> 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

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/3] virtual/cargo: drop virtual

William Hubbs
On Mon, Oct 28, 2019 at 10:18:17AM +1300, Kent Fredric wrote:
> On Sun, 27 Oct 2019 12:05:02 -0500
> William Hubbs <[hidden email]> 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

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/3] virtual/cargo: drop virtual

Kent Fredric-2
On Mon, 28 Oct 2019 10:34:40 -0500
William Hubbs <[hidden email]> 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*.

attachment0 (849 bytes) Download Attachment
12