On 09/27/2015 03:52 PM, James wrote: > >> 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. > > I think that this is what GLEP-64 is all about. Enhancing the functional > utilityh of the VDB with a DAG (Directed Acyclic Graph)? >
AFAIK, that GLEP is just about standardizing what goes in the VDB. The VDB isn't specified in the PMS either, but all package managers need to record e.g. what files were installed by the package. The GLEP would standardize some of that stuff, and in the future, the PMS would give you a way to read it reliably. The dynamic dependencies issue is more about the contents of the VDB being wrong. >> 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. > > There is no proper mechanism to accurately track all of these issue, > currently, or did I miss this point? The proper mechanism is "don't do that." The rules for when (not) to revbump could go on for pages, if there was anyone qualified to write them -- and I'm not convinced there is. The only safe thing to do is always revbump unless you're damned sure that you're an exception.
