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 <ken...@gentoo.org> wrote: >>> >>>> On Fri, 25 Oct 2019 15:03:39 -0700 >>>> Georgy Yakovlev <gyakov...@gentoo.org> wrote: >>>> >>>>> not used anymore >>>>> >>>>> Closes: https://bugs.gentoo.org/695698 >>>>> Signed-off-by: Georgy Yakovlev <gyakov...@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.
signature.asc
Description: OpenPGP digital signature
