I think the important thing to realize here is that the actual life times of variables is determined by the structure of your program, where/when those variables are created and where when they are destroyed.
A typical local variable in a function, say some struct, only lives as long as that function takes to run. The variable comes into life when you declare it and dies when the function returns.
You could pass references down though calls to a thousand functions to a call depth of a hundred, say, and all those called functions are referencing something with a lifetime of the original top level function. When everything returns back up the call stack and out the top level function the variable is gone.
So life time is infectious that way. Because of how you wrote your code.
With that in mind we see that adding life time, tick mark, annotations to a variable does not "specify" or change it's life time at all. They are required sometimes to help the compiler when it cannot figure things out, when life times are ambiguous.
Given the above we see that the dependencies are not created by the lifetime tick-marks, they are inherent in your code structure.
Luckily in all my application code I don't think I have even one life time tick-mark. When data needs to hang around longer than the scope of it's creation it can be wrapped in some smart pointer, an Rc or Arc, say. Or one can use .clone() to replicated it around the place, provided that is not too expensive an operation.
If you can stand watching a live coding video for an hour Jon Gjengset has an excellent exposition of life times here: " Crust of Rust: Lifetime Annotations": https://www.youtube.com/watch?v=rAl-9HwD858&t=4663s. He has a great style.