[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] version/slot locked dependencies in eclasses like autotools.eclass and vala.eclass
From:       Zac Medico <zmedico () gentoo ! org>
Date:       2018-01-24 2:36:52
Message-ID: b7c56958-7bb4-8c95-1a7f-2d3d95d97c90 () gentoo ! org
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


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" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]