Re: [gentoo-user] dynamic deps, wtf are they exactly

[Alan McKinnon]

On 27/09/2015 19:26, Michael Orlitzky wrote:
> On 09/27/2015 11:07 AM, Alan McKinnon wrote:
>> Does anyone here know what dynamic deps are exactly, how they work and
>> can describe them?
>>
>> There's lots of talk over on -dev about getting rid of them and the
>> closest description is from Ciaran, something like:
>>
>> "ancient shit that never worked right, involving phases of the moon"
>>
>
> "Dynamic dependencies" is a portage option. The abridged version is:
> whenever you go to install/update something, some of its dependencies
> may already exist on your machine. For example, if I go to install gimp
> right now, gtk is already there.
>
> With dynamic deps, portage will scan (that is, execute) all of the
> ebuilds for installed packages that could affect the dependency graph.
> If any of those ebuilds have changed, portage will use the new
> information rather than the info present when you originally installed
> the package. So if the gtk ebuild (that I installed a month ago) has
> been altered, portage will re-read it on the fly, ignoring what was in
> there a month ago.
>
> too short; didn't explain?

Nope, I see a problem already :-)

If portage can't reliably tell if the ebuild changed, the cache may or
may not be valid and portage wouldn't know.


> When you install a package, its dependencies are recorded in the VDB:
>
>   $ cat /var/db/pkg/app-editors/nano-2.3.6/RDEPEND
>   >=sys-libs/ncurses-5.9-r1[unicode] sys-apps/file
>
> That's nice, because now if you want to install or update something
> else, portage doesn't have to re-execute every ebuild/eclass that could
> possibly affect the new thing -- it only has to check the VDB.
>
> But, if I'm the maintainer of nano and I change that ncurses dependency
> (let's say I drop it), then I have to make a revision bump on nano.
> Otherwise, the wrong dependency would stay recorded on everyone's
> system, and portage would happily use the recorded deps.
>
> I guess at some point there were a bunch of devs who were messing with
> dependencies and not bothering to make revision bumps. This can cause
> users pain, so portage added a new option to ignore the cache and rescan
> every single relevant ebuild/eclass for sneaky dependency changes. This
> ensures that portage has the correct dependencies in its head while it's
> doing resolution, but is much slower.
>
> And then that mode was made default, which is where we are today. It
> doesn't sound that bad so far -- just a tradeoff between speed and the
> risk of using an incorrect cached dependency.
>
> Buuuuuuutttttt dynamic-deps mode doesn't always kick in. It interacts
> weirdly with subslots and other things. If portage can't find the same
> ebuild to scan, it will find one that "looks like it." If that doesn't
> work, it's supposed to fall back to the cache. Nobody has a flow chart
> of exactly how this works. It's all in the code and there's no
> specification.
>
> And, there are other package managers besides portage. When developers
> rely on dynamic deps and skip revision bumps, they're screwing users of
> paludis and pkgcore (and you, now that you have dynamic deps disabled).
> None of the magic is mentioned in the PMS, so you really can't rely on
> it and revbumps are needed regardless.


Now it all makes sense, as a bonus I now see why why so many senior devs
are so pedantic about revbumps (they have reason).

Now that I know what the symptom will be, are bug reports useful?


-- 
Alan McKinnon
alan.mckinnon@×××××.com