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? 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.
