| 1 |
On 09/27/2015 11:07 AM, Alan McKinnon wrote: |
| 2 |
> Does anyone here know what dynamic deps are exactly, how they work and |
| 3 |
> can describe them? |
| 4 |
> |
| 5 |
> There's lots of talk over on -dev about getting rid of them and the |
| 6 |
> closest description is from Ciaran, something like: |
| 7 |
> |
| 8 |
> "ancient shit that never worked right, involving phases of the moon" |
| 9 |
> |
| 10 |
|
| 11 |
"Dynamic dependencies" is a portage option. The abridged version is: |
| 12 |
whenever you go to install/update something, some of its dependencies |
| 13 |
may already exist on your machine. For example, if I go to install gimp |
| 14 |
right now, gtk is already there. |
| 15 |
|
| 16 |
With dynamic deps, portage will scan (that is, execute) all of the |
| 17 |
ebuilds for installed packages that could affect the dependency graph. |
| 18 |
If any of those ebuilds have changed, portage will use the new |
| 19 |
information rather than the info present when you originally installed |
| 20 |
the package. So if the gtk ebuild (that I installed a month ago) has |
| 21 |
been altered, portage will re-read it on the fly, ignoring what was in |
| 22 |
there a month ago. |
| 23 |
|
| 24 |
too short; didn't explain? |
| 25 |
|
| 26 |
When you install a package, its dependencies are recorded in the VDB: |
| 27 |
|
| 28 |
$ cat /var/db/pkg/app-editors/nano-2.3.6/RDEPEND |
| 29 |
>=sys-libs/ncurses-5.9-r1[unicode] sys-apps/file |
| 30 |
|
| 31 |
That's nice, because now if you want to install or update something |
| 32 |
else, portage doesn't have to re-execute every ebuild/eclass that could |
| 33 |
possibly affect the new thing -- it only has to check the VDB. |
| 34 |
|
| 35 |
But, if I'm the maintainer of nano and I change that ncurses dependency |
| 36 |
(let's say I drop it), then I have to make a revision bump on nano. |
| 37 |
Otherwise, the wrong dependency would stay recorded on everyone's |
| 38 |
system, and portage would happily use the recorded deps. |
| 39 |
|
| 40 |
I guess at some point there were a bunch of devs who were messing with |
| 41 |
dependencies and not bothering to make revision bumps. This can cause |
| 42 |
users pain, so portage added a new option to ignore the cache and rescan |
| 43 |
every single relevant ebuild/eclass for sneaky dependency changes. This |
| 44 |
ensures that portage has the correct dependencies in its head while it's |
| 45 |
doing resolution, but is much slower. |
| 46 |
|
| 47 |
And then that mode was made default, which is where we are today. It |
| 48 |
doesn't sound that bad so far -- just a tradeoff between speed and the |
| 49 |
risk of using an incorrect cached dependency. |
| 50 |
|
| 51 |
Buuuuuuutttttt dynamic-deps mode doesn't always kick in. It interacts |
| 52 |
weirdly with subslots and other things. If portage can't find the same |
| 53 |
ebuild to scan, it will find one that "looks like it." If that doesn't |
| 54 |
work, it's supposed to fall back to the cache. Nobody has a flow chart |
| 55 |
of exactly how this works. It's all in the code and there's no |
| 56 |
specification. |
| 57 |
|
| 58 |
And, there are other package managers besides portage. When developers |
| 59 |
rely on dynamic deps and skip revision bumps, they're screwing users of |
| 60 |
paludis and pkgcore (and you, now that you have dynamic deps disabled). |
| 61 |
None of the magic is mentioned in the PMS, so you really can't rely on |
| 62 |
it and revbumps are needed regardless. |
Archives