Martin Vaeth <martin <at> mvath.de> writes: > > James <wireless <at> tampabay.rr.com> wrote: > > > > Basically from my point of view, something like TUP [1] is needed so > > that at dependency check time you only list files that need > > attention (linking, loading, compiling etc) thus speeding up the > > update processes for the Package Manager (portage). > > This is a misunderstanding (originally already from Michael). > The issue is not at all about speed of portage - reading one or > the other file takes the same amount of time. > (And having a dependency graph of files would help concerning > speed only in the very rare situation that no file involving > your current package dependency tree does change.)
One aspect of the problem, but you are partially correct. > The whole issue is only about the policy: If the dependency > information of the installed package and of the current > package differs - what is the "correct" information? DAG's, from 'graph theory' are often used to form the basis of more advanced tool, including dependencies between the files, inlcuding date changes of last compile/touch times. > For each choice, it is possible to give examples where > the policy leads to a bad situation, so both, > static deps as well as dynamic deps can break in > certain situations. It is only a question which breakage > you consider more severe and/or harder to recognize/fix > by the user. Exactly. The current tools are insufficient, because the data necessary to build sufficient tools with ever evolving logic constraints form a myriad of system requirements, is insufficient; hence what Blueness refers to as a "Direcent linkages" is a a subset of what a full blown DAG can do. I use TUP et. al. as examples where a DAG is use to minimize the item listing for re-compile. But that is by no means the only usage of a DAG or similar structural enhancement to the tools that can be built. > Making more revbumps will increase the chance of > no breakage - in case of static deps only for users > who sync and update sufficiently frequently - > of course at the cost of redundant recompiles. Yes, DAGs can track timestamps and many other forms of data, and organize it to for easy parsing. > >> 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. True, but you are looking antedotally, not with the lens of developing tool that keep systems, robustly pristine; hence the struggles with package management. > This is historically not correct. Dynamic deps had always been > the only way portage treated dependencies - static deps have only > been used as a fallback and (unfortunately) with the introduction > of subslots. > Once more: It is not about speed, but about: What *are* the > "correct" dependencies? The ones referring to an historical tree > which - especially if you did not update for a long time - > might have almost nothing in common with the current tree > (static deps), or the ones referring to current tree > (dynamic deps)? Corrent. But with a DAG approach, you can develop tools that solve these and newer, unforseen problems. A DAG or a collection of DAGS can lead to a fully characterized system, where every file, and it's inter-related relationships, is tracked. This approach will allow those interested the ability to develop system tools for ensuring a system is and remains, pristine. Object oriented paradyms result in lots of "slop" and cruft on a system. > With static deps, you will have a strange mixture of historical > dependencies and current ones for the updates. > With dynamic deps, the tree might not be appropriate for your > installed packages. Ever look closing, manually parsing up and down the directory structure of an older gentoo install, say a few years? Cruft abounds. Cruft leads to the 'dark side' of computing. *every file* should be fully accounted for, have it's relationships mapped and documented, including timestamps. That one reason why commercial, embedded product systems, just run for years and years, without intervention. > > There is no proper mechanism to accurately track all of these issue, > > currently, or did I miss this point? > > There is no way to automatically decide correctly which of > two differing informations should be used... Correct, so you build DAGs for data, then parse it, statistically or manually and discern problems. DAGs are fundamental and probably the singular most important thing you learn in one of your most important computer science undergraduate course in graph theory. Computers are all about repeatability and assurances to accuracy. DAGs are a fundamental tool for these sorts of scenarios. hth, James
