| 1 |
On 09/27/2015 03:52 PM, James wrote: |
| 2 |
> |
| 3 |
>> That's nice, because now if you want to install or update something |
| 4 |
>> else, portage doesn't have to re-execute every ebuild/eclass that could |
| 5 |
>> possibly affect the new thing -- it only has to check the VDB. |
| 6 |
> |
| 7 |
> I think that this is what GLEP-64 is all about. Enhancing the functional |
| 8 |
> utilityh of the VDB with a DAG (Directed Acyclic Graph)? |
| 9 |
> |
| 10 |
|
| 11 |
AFAIK, that GLEP is just about standardizing what goes in the VDB. The |
| 12 |
VDB isn't specified in the PMS either, but all package managers need to |
| 13 |
record e.g. what files were installed by the package. The GLEP would |
| 14 |
standardize some of that stuff, and in the future, the PMS would give |
| 15 |
you a way to read it reliably. |
| 16 |
|
| 17 |
The dynamic dependencies issue is more about the contents of the VDB |
| 18 |
being wrong. |
| 19 |
|
| 20 |
|
| 21 |
>> I guess at some point there were a bunch of devs who were messing with |
| 22 |
>> dependencies and not bothering to make revision bumps. This can cause |
| 23 |
>> users pain, so portage added a new option to ignore the cache and rescan |
| 24 |
>> every single relevant ebuild/eclass for sneaky dependency changes. This |
| 25 |
>> ensures that portage has the correct dependencies in its head while it's |
| 26 |
>> doing resolution, but is much slower. |
| 27 |
> |
| 28 |
> There is no proper mechanism to accurately track all of these issue, |
| 29 |
> currently, or did I miss this point? |
| 30 |
|
| 31 |
The proper mechanism is "don't do that." The rules for when (not) to |
| 32 |
revbump could go on for pages, if there was anyone qualified to write |
| 33 |
them -- and I'm not convinced there is. The only safe thing to do is |
| 34 |
always revbump unless you're damned sure that you're an exception. |
Archives