On 01/21/2018 08:57 PM, Michael Orlitzky wrote: > On 01/21/2018 11:24 PM, Zac Medico wrote: >> >> 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? >> > > This changes the deps in stable ebuilds, and was already a no-no. > > If the dependencies are to remain in the eclasses, then the eclasses > should get a new revision when those dependencies change. Afterwards, > the consumers can be revbumped and stabilized normally to utilize the > new eclass.
Sounds good! >> Should we tell users to use the emerge --changed-deps=y option? Maybe >> make --changed-deps=y a default setting? >> > > Our tree shouldn't require a portage-only option to work. Besides, it's > better engineering to have the one person who makes the change alert the > rest of us. Having a million people poll "Did somebody change this? How > about now?" constantly is silly. Okay, think I'll prepare a news item suggesting to use --changed-deps=y if necessary for the initial transition to --dynamic-deps=n. -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature
