[issue37] Debfoster like package removal

[Daniel Arnold at Labix Tracker]

Daniel Arnold <arnomane at gmx.de> added the comment:

Some additional interface and algorithmic ideas came into my mind that even go                    
beyond Defoster.               
                 
Let's take the following situation: Like above someone installed a single                    
Gnome app at at pure Qt/KDE desktop and now removes this app without removing                    
its dependencies. The problem is that now a larger number of libs is on top                    
level of dependencies but joe user has noe clue that they were installed                    
together for a single purpose and thus should also be removed together.                
                
But distros are writing install/uninstall logs that could be analyzed and                
could be checked for removed packages. For these removed packages the                
dependencies get also calculated and now you can reconstruct the root of a               
dependency tree and can group the now independent top level dependencies                
of the Gnome libs of our example together.               
               
So I now suggest an user interface where you have the top level packages like               
a tree with subgrouping the dependencies that only belong to this package (in             
that current installation, as the packages belonging to only one top package             
can change if you install more packages).             
             
So it would be look like this (in case the top leve application wasn't             
removed):               
               
[x][x] Application X               
 |               
  ---[x] Lib X               
 |               
  ---[x] Lib Y               
 |               
  ---[x] Lib Z               
            
If you unceck the first [x] at Application X all subpackages belonging to it         
get unchecked automatically too (but you can check single packages below            
this top package again so that they will be kept). If you uncheck the second         
[x] at Application X only the application gets removed but not the         
dependencies. As long as the second [x] at Application X is not unchecked the     
dependencies are greyed out as you cannot remove them as long as the package     
that depends from them is installed.     
         
In case the top Application was already removed the interface looks like that         
(note the empty [ ] at Application X):           
          
[x][ ] Application X               
 |               
  ---[x] Lib X               
 |               
  ---[x] Lib Y               
 |               
  ---[x] Lib Z               
        
So you can either reconstruct the package and reinstall the application        
package if you check the [ ] or remove the whole thing entirely if you also       
uncheck the first [x].

----------
status: unread -> chatting

_______________________________________
Labix issue tracker <tracker at labix.org>
<http://tracker.labix.org/issue37>
_______________________________________