On 01/23/2018 01:06 AM, Mart Raudsepp wrote: > 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.
Is it so bad if users have to become accustomed to using --changed-deps=y for some time, until we get things sorted out? I feel like there is never going to be a time when everyone is ready for this all at once, and defaulting --dynamic-deps=n serves as a way to prevent these issues from being entirely forgotten about. For vala_depend, maybe something like this works: VALA_MIN_API_VERSION="0.32" translates to >=dev-lang/vala-0.32 VALA_MAX_API_VERSION="0.36" translates to <dev-lang/vala-0.37 Both VALA_MIN_API_VERSION and VALA_MAX_API_VERSION unset translates to simply to dev-lang/vala. For vala_best_api_version, maybe use best_version, with atoms generated using VALA_MIN_API_VERSION and VALA_MAX_API_VERSION if the ebuild set them. -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature