From: William Hubbs <williamh@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
Date: Sat, 26 Oct 2019 18:55:11 -0500 [thread overview]
Message-ID: <20191026235511.GB16818@linux1.home> (raw)
In-Reply-To: <30114cca-2851-4c22-31f6-575eb851ac88@veremit.xyz>
[-- 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 --]
next prev parent reply other threads:[~2019-10-26 23:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-25 22:03 [gentoo-dev] RFC: cargo.eclass changes and virtual/cargo retirement Georgy Yakovlev
2019-10-25 22:03 ` [gentoo-dev] [PATCH 1/3] cargo.eclass: do not use virtual/cargo anymore Georgy Yakovlev
2019-10-25 22:03 ` [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual Georgy Yakovlev
2019-10-26 3:59 ` Kent Fredric
2019-10-26 4:24 ` Michael Everitt
2019-10-26 6:34 ` Francesco Riosa
2019-10-26 7:17 ` Kent Fredric
2019-10-26 9:14 ` Dirkjan Ochtman
2019-10-26 9:17 ` Michał Górny
2019-10-26 22:35 ` William Hubbs
2019-10-26 23:14 ` Michael Everitt
2019-10-26 23:55 ` William Hubbs [this message]
2019-10-27 1:42 ` Michael Everitt
2019-10-27 10:09 ` James Le Cuirot
2019-10-27 7:36 ` Kent Fredric
2019-10-27 17:05 ` William Hubbs
2019-10-27 21:18 ` Kent Fredric
2019-10-28 15:34 ` William Hubbs
2019-10-29 16:43 ` Kent Fredric
2019-10-29 16:48 ` Michał Górny
2019-10-29 17:27 ` William Hubbs
2019-10-30 8:19 ` Kent Fredric
2019-10-30 14:26 ` William Hubbs
2019-10-30 14:28 ` William Hubbs
2019-10-30 14:49 ` Kent Fredric
2019-10-30 15:52 ` William Hubbs
2019-10-30 20:49 ` Kent Fredric
2019-10-25 22:03 ` [gentoo-dev] [PATCH 3/3] cargo.eclass: use verbose cargo invocation Georgy Yakovlev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191026235511.GB16818@linux1.home \
--to=williamh@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox