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 [email protected]
