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