Fair enough questions. Here goes:
1) Re. my comments on the ZW forums.
-- I re-read things and agree that my recent post may have come across as a bit harsh compared to the actual discussion. I retract some
of what was said. My reasoning follows:
2) Re. the actual discussion
-- Re. Shador's script:
I did thank him, but do not ignore my quote in the same post:
I suppose my point is that if this feature would prove useful and could make quick work of identifying unnecessary deps of a package I no longer want (a dep I know is not from the base system), wouldn't it be nice to have it around vs. using bash scripts?
-- Re. my summary:
actually, I think my post does describe it pretty well. It actually did occur pretty close to this. You only disagree with the 'problems not answered' part, right? The key is the last point:
Me: why not just make this a feature rather than requiring a shell script? In fact, if it's about providing 'power' and advanced usage, I'd rather know how to find what the orphan deps are than be limited to never knowing about them.
What is confusing about this? The topic was not listed as [solved], I had valid questions/points still remaining. I do agree that I posted that 'all my questions were answered'... this was incorrect. I still had questions regarding the actual philosophy of the solutions and functionality being discussed. Perhaps I should have written, instead:- Thanks. My questions about how to somewhat hack-it-along are answered.
- Given that I need to hack-it-along, is there a better way, because this is still not answered for me?
3) Re. slapt-get
-- Re. taking it up with the owner:
Good point. I was mostly taking up the issue with Salix since it was the distro I was using and it chose to adopt slapt-get/gslapt. Not sure where better to ask a question about package management philosophy and usage on the distro I'm actually using.
4) Re. slapt-get... on the other hand
-- My issue is, somewhat, with Salix as my discussion with gapan and company indicated that they seem to prefer slapt-get's operation and support it.
-- So..., while my 'option' (slapt-get -L) is a proposal for the owner, the decision to use slapt-get and slapt-get alone is a question/issue with those who chose that package management system for their distro.
-- My posts about Salix are revealing of my frustrated nature:
---- I love Slack derivatives and have been frustrated at finding a comparable distro to Zenwalk, which I love, that is available in 64bit
---- So far, the options I've looked at are not as good as Zenwalk in terms of overall polished-ness (not 'eye-candy', but polished packages that just work, OS staying out of my way, etc).
-- I disagree that Slackware is benefitted by a complete lack of dependency tracking
-- The main issue comes down to this:
---- Individuals want
to know what's on their system. Do you like stale deps sitting around?
---- Since there is no dep info, or whatever dep info there is mostly not useful except when installing, I am left to keep a text file with my own dep info
---- Where do I get this dep info? Either from what is listed in the package info, in the Salix repo information, or what the app complains about when I try to start it...
---- So, in the end, either I'm tracking dep info put together by the packager, by the maintainer, or by the Salix repo dep info by Salix devs.
-- Given the above facts, I see no issue with providing a simple method to tell the user what is and is not required by other packages since the info is there already
---- Yes, the script works... the point is that if it's a nice bit of info to have, why not actually have some type of utility in Salix to do this for me rather than making me post in a forum to figure it out?
-- My questions have been more targeted at philosophy and the response I got seemed to 1) support that somehow this is a benefit rather than a hindrance, 2) hide behind 'power user abilities' when supporting tracking dep info, but not provide the 'power user ability' of finding orphans because users might break their system (issue: allowing 'power user abilities' is exactly what lets me do what I want both to have freedom to make my computer what I want and, necessarily, what lets me break my system), and 3) encourage what I would call 'limp-along' solutions in the place of supported methods which could easily be provided by Salix.
---- The point about potentially removing something important is silly, as Zenwalk easily fixes this by listing things by category (category 'System' issues a 'heads up' not to remove something before thinking about it) rather than only alphabetically...
6) Other quotes:
-- Feel free to take from more balanced/flattering sources as well
-- A review of my experience is here
-- Quote from right above where you quote-mined that explains exactly
what I'm trying to illustrate:
- Re. dependency info: this is super awesome and one of the reasons I had such a difficult time with Salix. It was also a souce of disagreement when I posted about their forums. I found it odd that:
--- One on hand, went through the difficult time of creating lists of dependencies for entire Slack repos
--- One the other hand, did not have a package manager what would tell me what orphans there were
-- Also, I did mention in the same post you referred to that 13.0.2 was better than my initial experience.
Where does this leave us? Not exactly sure... I'm still pretty solid in what I thought and wrote and think that all of this can be summarized by your just not liking that I wrote 'all my problems are answered, thanks Shador' when that's not what I meant... Had I not written that, where would the issue be?
I still stand by there being easy improvements to slapt-get that could make things easier. It strikes me as trying to have a package manager without providing any of the benefits normally associated with a package manager.
Riddle me this: why create all that dep info to set Salix apart and then not let me use it in an automated fashion other than when installing?
What do you think about my response?