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
signature.asc
Description: Digital signature
