On Mon, 2018-01-22 at 12:07 -0800, Zac Medico wrote:
> On 01/22/2018 05:14 AM, Mart Raudsepp wrote:
> > On Sun, 2018-01-21 at 20:24 -0800, Zac Medico wrote:
> > > Hi,
> > > 
> > > In sys-app/portage-2.3.20, emerge now defaults to --dynamic-
> > > deps=n.
> > > This
> > > means that unless people explicitly set
> > > EMERGE_DEFAULT_OPTS="--dynamic-deps=y" they're going to have to
> > > rebuild
> > > packages any time that the runtime dependencies of those packages
> > > need
> > > to be updated. It's possible to trigger these rebuilds using the
> > > emerge
> > > --changed-deps=y option.
> > > 
> > > Some eclasses like autotools.eclass and vala.eclass generate
> > > version/slot locked dependencies that cause the dependencies of
> > > inheriting ebuilds to change when the versions in the eclasses
> > > are
> > > updated. If possible, it would be nice to avoid this version/slot
> > > locking. If not possible, then what should be do?
> > 
> > These are mostly build time only depends, why should the user now
> > all
> > of a sudden care before an unrelated rebuild or upgrade, which
> > would
> > actually matter only then, not before?
> 
> For various reasons, current versions of portage enable the
> --with-bdeps=y option by default [1]. Basically, failing to update
> installed packages and possibly leaving them with broken dependencies
> is
> not really a sane default behavior.
> 
> [1] https://bugs.gentoo.org/598444

Sure, and now in combination with --with-bdeps=y and --dynamic-deps=n,
thing are bad for these cases. I'm saying that users shouldn't have to
care about these cases.

That said, I'm not sure why the slot deps have to be there for the
cases $vala_depend is put into DEPEND; those might just be able to be
an unbounded dev-lang/vala. However where they are truly needed in
RDEPEND, they will need something here, just not sure := is going to
cut it. Maybe the interface is stable enough that anything will be fine
with the newest version by now, but not sure. Bottom-line is, we aren't
going to be revbumping all the vala.eclass users as a new GNOME version
with new vala appears. The idea is to get everyone to use the new
versions in stable ASAP, not rebuild all of them in stable first.
In any case, this will need investigation, and it is not a good time to
have such an investigation forced upon us with our current limited
manpower.


Reply via email to