Zac Medico posted on Sun, 21 Jan 2018 22:20:21 -0800 as excerpted:
> 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!
How does that work with live-vcs ebuilds, aka - ebuilds?
To date I've seen very few if any --rX ebuilds, I've assumed because
they'll be rebuilt if the sources change anyway, and with @smart-live-
rebuild upstream changes are detected and trigger rebuilds automatically.
But now we're talking gentoo level dependency changes that either don't
match a specific upstream change or that occur *after* the upstream
change, so there may /be/ no timely upstream update to trigger a rebuild.
Does this then mean we should be getting --rX revision bumps now, for
gentoo level dependency changes?
If so, gentoo/kde's overlay... and I since I run live-git of nearly
everything kde here... are in for quite some hundreds-of-packages-at-once
fun when those eclass dep-bumps occur...
(Tho it can't be /that/ bad, since I've been running with --dynamic-deps=n
for years now, and without --changed-deps for I'd guess a year or so
now. And upstream does mass version and dep bumps regularly already,
triggering the mass rebuilds even if that's the only commit, so I suppose
another triggered rebuild when gentoo/kde revbumps after dep-bumping to
reflect what upstream already did, won't be /that/ much different or
/that/ much more work. Only now I guess I'll be seeing it in --rX
revbumps, too.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
