FS#7224 - Keep track of reverse dependencies
Attached to Project:
Pacman
Opened by Scott H (stonecrest) - Sunday, 20 May 2007, 22:54 GMT
Last edited by Allan McRae (Allan) - Monday, 11 September 2023, 13:49 GMT
Opened by Scott H (stonecrest) - Sunday, 20 May 2007, 22:54 GMT
Last edited by Allan McRae (Allan) - Monday, 11 September 2023, 13:49 GMT
|
Details
If you run pacman -Qi on an orphaned package, you currently
only get information that says:
"Install Reason : Installed as a dependency for another package" It would be very useful to track these "reverse dependencies" or "parents" so that we can, e.g., know which package actually brought in this orphaned package. |
This task depends upon
Closed by Allan McRae (Allan)
Monday, 11 September 2023, 13:49 GMT
Reason for closing: Won't implement
Monday, 11 September 2023, 13:49 GMT
Reason for closing: Won't implement
1. --asdeps
2. The real parent doesn't say too much, maybe the real parent doesn't exist on your system now (see gtk2 for example), but the package is still needed. Then what information can you get from the "initial" parent?
3. What if you install 3 packages at the same time and all pulls bar as their dependency (so even the "initial" parent is not well defined neither)
2. It's true that there may be times where the parent is removed (albeit infrequent). But that doesn't change the fact that when you pacman -Qi the child, it's still useful information to know what the parent originally was that brought in this package as a dep.
3. I wouldn't think there has to be 1 and only 1 parent.
I agree with what Nagy said, that this causes some implementation problems. But maybe we could just store the initial RequiredBy entry, when a package is installed / upgraded. Though that would be yet another field cluttering our database.
Otherwise just do incremental backups of this output : LANG=C pacman -Qi | grep -E "Name|Required" and you will know :)
* %REASON%: 0/1 integer to char field
* When package is initially pulled in, write package name that pulled it in.
* If package is uninstalled and it is found in another package's reason field, update reason field if possible to a still installed package else leave it alone.
* To check orphans- if reason value not in localdb, it is an orphan.
Alternatively, we could make this a multivalued field that contains the broadest list possible of all packages that have ever required this one, and keep it updated. Things would never be removed as long as it was a "installed as dep". This would probably make a bit more sense. --asdeps would be recorded as some special value, e.g. <marked explicitly as dependency>.