| 1 |
On Mon, 2018-01-22 at 12:07 -0800, Zac Medico wrote: |
| 2 |
> On 01/22/2018 05:14 AM, Mart Raudsepp wrote: |
| 3 |
> > On Sun, 2018-01-21 at 20:24 -0800, Zac Medico wrote: |
| 4 |
> > > Hi, |
| 5 |
> > > |
| 6 |
> > > In sys-app/portage-2.3.20, emerge now defaults to --dynamic- |
| 7 |
> > > deps=n. |
| 8 |
> > > This |
| 9 |
> > > means that unless people explicitly set |
| 10 |
> > > EMERGE_DEFAULT_OPTS="--dynamic-deps=y" they're going to have to |
| 11 |
> > > rebuild |
| 12 |
> > > packages any time that the runtime dependencies of those packages |
| 13 |
> > > need |
| 14 |
> > > to be updated. It's possible to trigger these rebuilds using the |
| 15 |
> > > emerge |
| 16 |
> > > --changed-deps=y option. |
| 17 |
> > > |
| 18 |
> > > Some eclasses like autotools.eclass and vala.eclass generate |
| 19 |
> > > version/slot locked dependencies that cause the dependencies of |
| 20 |
> > > inheriting ebuilds to change when the versions in the eclasses |
| 21 |
> > > are |
| 22 |
> > > updated. If possible, it would be nice to avoid this version/slot |
| 23 |
> > > locking. If not possible, then what should be do? |
| 24 |
> > |
| 25 |
> > These are mostly build time only depends, why should the user now |
| 26 |
> > all |
| 27 |
> > of a sudden care before an unrelated rebuild or upgrade, which |
| 28 |
> > would |
| 29 |
> > actually matter only then, not before? |
| 30 |
> |
| 31 |
> For various reasons, current versions of portage enable the |
| 32 |
> --with-bdeps=y option by default [1]. Basically, failing to update |
| 33 |
> installed packages and possibly leaving them with broken dependencies |
| 34 |
> is |
| 35 |
> not really a sane default behavior. |
| 36 |
> |
| 37 |
> [1] https://bugs.gentoo.org/598444 |
| 38 |
|
| 39 |
Sure, and now in combination with --with-bdeps=y and --dynamic-deps=n, |
| 40 |
thing are bad for these cases. I'm saying that users shouldn't have to |
| 41 |
care about these cases. |
| 42 |
|
| 43 |
That said, I'm not sure why the slot deps have to be there for the |
| 44 |
cases $vala_depend is put into DEPEND; those might just be able to be |
| 45 |
an unbounded dev-lang/vala. However where they are truly needed in |
| 46 |
RDEPEND, they will need something here, just not sure := is going to |
| 47 |
cut it. Maybe the interface is stable enough that anything will be fine |
| 48 |
with the newest version by now, but not sure. Bottom-line is, we aren't |
| 49 |
going to be revbumping all the vala.eclass users as a new GNOME version |
| 50 |
with new vala appears. The idea is to get everyone to use the new |
| 51 |
versions in stable ASAP, not rebuild all of them in stable first. |
| 52 |
In any case, this will need investigation, and it is not a good time to |
| 53 |
have such an investigation forced upon us with our current limited |
| 54 |
manpower. |
Archives