Package list 'info' dependencies question.

Trev

The Dumb One
Two really.
1. Why is 'mongoose' red in my installed package list and has a red bang (!) against it?
2. Can someone please explain, with example(s), the terminology of the 'depends' list when you hit the 'info' button against a package. For instance, what is 'root set:'? I have tried to understand what it all means, but failed miserably.
 
1. Why is 'mongoose' red in my installed package list and has a red bang (!) against it?
The exclamation mark means that the package is no longer available in the repository, which is right for the mongoose package. If you hover your mouse over the exclamation mark it should show a pop-up that explains that. Feel free to uninstall mongoose, it isn't needed any more.
2. Can someone please explain, with example(s), the terminology of the 'depends' list when you hit the 'info' button against a package. For instance, what is 'root set:'? I have tried to understand what it all means, but failed miserably.
It just shows you what the dependencies are for a package. So a simple example is tunefix

Code:
Root set:
  tunefix
What depends on root set
    tunefix-update 1.0.21    depends on tunefix (>= 1.5.2)

That tells you that tunefix is depended on by tunefix-update. The idea is to tell you what other packages depend on this one and would therefore inhibit its removal.

Root set just means "the thing we're looking at" and the next line is effectively "what depends on the thing we're looking at?"

Here's another example, for inotify-tools

Code:
Root set:
  inotify-tools
What depends on root set
    auto-unprotect 2.0.2    depends on inotify-tools
    recmon 2.2.1-1    depends on inotify-tools

Both auto-unprotect and recmon need inotify-tools to be installed.
 
Thanks af123. I'll get on and bin mongoose (having hovered a bit).
Thanks for the other. I got the second stuff in your second example, as it's pretty understandable. But it was the 'root set' that I found unintelligible and couldn't 'get it'. Now you have explained that 'root set' is a kind of alias for what you are looking at, it has become much clearer.
Is there not a more instantly understandable method of describing these dependencies?
I'll have a gander at some more tomorrow after I have switched the box on. (Time for bed, methinks.)
 
The descriptions are generated by the standard tools, so have the UNIX-geek wording of the standard tools.
 
I guessed that, but not being a Unix geek, I didn't understand it.
What was/is confusing me a bit, is that I don't understand why full dependencies seem to be missing. For instance when you 'info' tunefix, you get the message posted by q=af123 above, telling you that tunefix-update depends on it, but when you 'info' tunefix-update you get
Code:
>>> opkg whatdepends tunefix-update
Root set:
  tunefix-update
What depends on root set

Done.
which gives no indication that tunefix-update depends on tunefix being present to 'work.
But I suppose if that's the way it is......
At least I now understand what 'root set' is all about.:)
 
The original idea of the function was to make it easier to see why a package was installed if you were considering removing it. Leave it with me and I'll change it to make it clearer and show dependencies in both directions.
 
I guessed that, but not being a Unix geek, I didn't understand it.
What was/is confusing me a bit, is that I don't understand why full dependencies seem to be missing. For instance when you 'info' tunefix, you get the message posted by q=af123 above, telling you that tunefix-update depends on it, but when you 'info' tunefix-update you get
Code:
>>> opkg whatdepends tunefix-update
Root set:
  tunefix-update
What depends on root set

Done.
which gives no indication that tunefix-update depends on tunefix being present to 'work.
But I suppose if that's the way it is......
At least I now understand what 'root set' is all about.:)
That's logical; tunefix does not depend on ...update to work, whereas ...update can't work without tunefix. The relationship is asymmetrical. A child is dependent on it's mother but a mother is not dependent on the child.
 
Hey af123. I would have understood that first time around.:D
That's logical; tunefix does not depend on ...update to work, whereas ...update can't work without tunefix.
That's the point I was trying to make. If I look at tunefix-update, I would sort of expected it to tell me that it depended on tunefix being there to work, but it doesn't.
But it seems that af123's mod above addresses that. Not sure how long that would make some of the lists though.
 
Last edited:
That's the point I was trying to make. If I look at tunefix-update, I would sort of expected it to tell me that it depended on tunefix being there to work, but it doesn't.
You don't need to know that. Anything tunefix-update needs will be automatically in place. The reason for the information is to check what would get upset by removing the package - in this case, nothing.

If you were to try to remove a package that something else depended on, it would fail - but you don't know why it failed unless you check for what's locking it.

However, that said, the revision provides clearer information.
 
That looks like a '/hiding to nothing' af123.:eek:
You don't need to know that. Anything tunefix-update needs will be automatically in place. The reason for the information is to check what would get upset by removing the package - in this case, nothing.
Exactly the reason for my query albeit that I don't need to know anything as it all 'just works' for me.
But, for instance: Can I remove wireless tools as I don't use a wireless connection? From the dependencies, it appears that "webif 1.4.2-5 depends on wireless-tools (>= 29-1)". But can I remove it or would it 'upset' webif? This is an example as I have no particular reason to remove it other than 'for interests sake'.
 
But that's fiddling around under the bonnet. I don't think WebIF critically depends on the presence of wireless-tools, but you would be removing a "component" rather than a "user-installed package". At the moment we only have an "advanced" subset in the package list; I think the nuts and bolts packages (components) need separating out as well, so they are hidden even with the advanced packages revealed. Then most users would only see the primary user-installed packages that can equally well be removed again, even if they engage with the trickier non-main-stream stuff.
 
Back
Top