Question on slapt-get and Salix repos

[jwhendy]

I followed the wiki's procedure for setting up an additional repository for dependency listing of slack packages. That is working great.

- Created /var/customRepo for my dependency supported slack repo by pointing adddepinfo.sh to http://slackware.oregonstate.edu/slackware64-13.0/ and populating the deps tree with no hitches.

I was going to go through (since I just got my system up) and prune what I don't want and found that none of the installed packages list any dep info. I have three listings in the 'Location' column in gslapt:

- /var/log/mount/salix/.../pkgname.txz: no dep info listed
- ./slackware64/*: dep info listed
- ./salix/*: dep info listed

Is there a way to get the dep info for the packages installed? There are no 'duplicated' with depinfo I can 'cheat' from (aalib is only found at the /var/log/mount/... location, not at ./slackware64 or ./salix).

Lastly I do realize that we already have a lot from Salix by being able to install a package and automatically have all its dependencies, but what about removing a package and all it's [un-depended-on] dependencies? Not to raise any flares, but the best example that comes to mind is netpkg. I suppose Synaptic does the same, I think, with 'mark for complete removal'. Is there any way to do this? It's a bummer to say, try KDE, and have beautiful automatic dependence resolution of all the qt libs and then have to track them all down by hand!

Thoughts? I guess these are two separate issues/questions. For simplicity:

1. How can I see the deps for the currently installed apps?
2. Is there anything wrong that everything that is installed is listed as being at /var/log/mount/salix...?
3. Is there a way to remove a package and it's un-depended-on dependencies?

So far, I'm digging Salix a lot. Just need to get some clarification!


Best regards,
John

[gapan]

1. How can I see the deps for the currently installed apps?

Dependency information is not included in the packages themselves. So there is no way to view dependency information unless you query the package database. You can do that with slapt-get, using slapt-get --show packagename. You might ask why gslapt doesn't do the same. The answer is fairly obvious, for any installed package, gslapt doesn't know if you have installed that from the repositories, or if you have (re-)built the package yourself and installed it locally, maybe changing some compile options that would result in a different dependency list anyway.

2. Is there anything wrong that everything that is installed is listed as being at /var/log/mount/salix...?

Not at all. That's exactly the location the packages were installed from during installation.

3. Is there a way to remove a package and it's un-depended-on dependencies?

There are two different things that you might mean by this:
1. If package A requires package B, and you remove package B, then A should be removed automatically as it would no longer work with package B. That is supported by synaptic, actually it's always forced by synaptic, but that's also the freedom you get in slackware compared to debian, you're not a slave to dependencies if you know what you're doing. There are many cases when someone has very valid reasons to do this.
2. If package A requires package B, and you remove package A and no other installed package requires package B, then you would want B to be removed too. That is not supported by synaptic. The "mark for complete removal" option in synaptic just removes all configuration files with the package. But that is what the "orphans" thing is about in netpkg. I consider this functionality dangerous to say the least. I know there have been many cases of false positives leaving behind a borked system. The user should know what he's removing from his system and do any removals consciously, not because some package manager told him so.

[jwhendy]

1. Re. dependency information
-- Sounds good for the most part. So I'd be able to query with the package name of a current installed package (e.g. xfce) with slapt-get using your --show option and see the dep info even though I can't from gslapt?

While that may work, I'm confused as to why it would give me that info from slapt-get but not be able to display in gslapt... isn't gslapt just giving the information in slapt-get in gui form? Or is it that with slapt-get --show I'm querying a repository (so I get general dep info) and gslapt is just showing the equivalent of slapt-get --installed so it only knows that package.txz is installed and not in what manner (from a repo with all deps, from source with only certain deps, etc.)?

2. Re. /var/log/mount...
-- Good to know

3. Re. automatically removing packages + deps
-- I meant the second option. I also appreciate the freedom to proceed in your first example and remove a dep and not have it's parent automatically removed.

Given the second option, I hear your case about netpkg orphans, but try this for example:
-- If Package A requires B, there are only two ways things could fail:
----- Removed when needed: package B is listed as a dep for package A and not listed as a dep for any other packages even though it is required by one or more of them. The auto-removal tool takes away both A and B and leaves another package broken because B should have stayed
----- Missed when un-needed: Package B is actually not listed as a dep so it isn't removed and I am left with a stale dep that I don't even know about

Option two is the better of the option as it only leaves an extra package, not a potentially broken system... but re. your manual vs. auto comment: what is the difference between me manually tracking down un-needed (orphan) deps vs. using an automated system? If we're reading the same lists (slapt-get --show packagename), wouldn't either way be in danger of removing something that was actually depended on if that output is false?

4. Also, assuming the manual way is the safest way to accomplish the above, say Package A depends on B -- how do I manually find out if B is depended on elsewhere? slapt-get --show * |grep B? Or will slapt-get --show packageB show me only the packages currently installed on my system that require B?


Best regards,
John

[gapan]

1. Re. dependency information

I thought I had already explained that but maybe I wasn't that clear. What gslapt shows is the installed package. Packages themselves include no dependency information, that is only in the dependency database in the repository. But when you do slapt-get --show, you're not showing properties of the installed package, you're showing properties that come straight from the dependency database.

3. Re. automatically removing packages + deps

The "removed when needed" example is the one that will cause all the problems. I will give you a couple of examples. There is no package that depends on sysvinit-scripts. A package manager that would search for "orphans", would show sysvinit-scripts as one and a user that doesn't really know what he's doing, will be prompted to remove it. That will only just leave him with a system that won't boot. Another example: I have an intel graphics card and therefore I need xf86-video-intel to run Xorg. This one is also not a dependency of any other package, so it would be labeled as "orphan" and if I remove it, I would have no Xorg anymore. And this one is trickier too, because if you have an nvidia for example, you can safely remove that same package with absolutely no problems whatsoever.

If you examine dependencies of packages in the repositories, you'll find that there are literally hundreds of packages that are absolutely needed to have a properly running system, but would be indicated as "orphans" anyway. And if you look in the zenwalk forums, you'll find many cases of "I just removed what netpkg told me was unnecessary and now nothing works".

The differences when you're removing packages manually, is that you are doing it consciously and you know exactly what you're removing and don't just do a couple of clicks, doing something that appears to be completely harmless while it isn't.

4. Also, assuming the manual way is the safest way to accomplish the above, say Package A depends on B -- how do I manually find out if B is depended on elsewhere? slapt-get --show * |grep B? Or will slapt-get --show packageB show me only the packages currently installed on my system that require B?

There is no direct way to do that with slapt-get/gslapt. You can use the PACKAGES.TXT files that hold all the package information from the repositories (both salix and slackware-with-deps repos) and some scripting to do that. For example listing all packages in the salix repository that depend on libvorbis would be:

Code: Select all

grep -B4 "REQUIRED.*libvorbis.*" PACKAGES.TXT |grep NAME

[Shador]

Try this:

Code: Select all

for i in `echo /var/log/packages/* | tr ' ' '\n' | sed -e 's;.*/\(.*\)-[^-]*-[^-]*-[^-]*;\1;'`; do
   test -z "`zcat /var/slapt-get/.http\:##salix.enialis.net#x86_64#13.0#PACKAGES.TXT.gz | grep -B4 "REQUIRED.*$i.*" |grep NAME`" \
   && echo "\`$i' is orphan"
done

I have as few as "472" orphans here, most of which apps and some system essentials like aaa_base, which definitely should never be removed.
I recommend you log the output with tee to a file.

[jwhendy]

@gapan
1. Re. dependency info
-- Gotcha. We were saying the same thing and I'm good now.

3. Re. automatically removing packages + deps
-- You make better examples; I had not thought of the issue of listing all orphans. I'm understanding better why it's hard to provide what I'm asking for... I want to look only at dependencies that are not part of the 'base' system, but it's impossible to cross check because people tailor their systems so differently that you could never have a standard set of packages to call the 'base' since users differ so much.

I think I'll proceed as I had with Zenwalk, then... each time I added a package I know I might remove, I simply wrote 'packageName: dep1, dep2, dep3...' in a text file so that when I got rid of it later I could track down the dependencies I knew were added at the time.

Even though perhaps the operation of netpkg is suspect... is it a bad thing to give the user at least the list of un-depended on packages? It seems that one one hand, we want a user to have complete control: I can remove a dependency of packageA without forcing packageA to be removed as well... but on the other hand I'm not allowed to have a tool available to have a simple look at packages with nothing depending on them.

I think that FreeBSD has it down nicely with the portmaster system talked about HERE:

Portmaster groups ports into four categories:

Root ports (no dependencies, not depended on)

Trunk ports (no dependencies, are depended on)

Branch ports (have dependencies, are depended on)

Leaf ports (have dependencies, not depended on)

You can list all the installed ports and search for updates using the -L option:

# portmaster -L
===>>> Root ports (No dependencies, not depended on)
===>>> ispell-3.2.06_18
===>>> screen-4.0.3
===>>> New version available: screen-4.0.3_1
===>>> tcpflow-0.21_1
===>>> 7 root ports
...
===>>> Branch ports (Have dependencies, are depended on)
===>>> apache-2.2.3
===>>> New version available: apache-2.2.8
...
===>>> Leaf ports (Have dependencies, not depended on)
===>>> automake-1.9.6_2
===>>> bash-3.1.17
===>>> New version available: bash-3.2.33
...
===>>> 32 leaf ports

===>>> 137 total installed ports
===>>> 83 have new versions available

Could it be that it's just the name 'orphan' that's the issue with how you think of netpkg? What if it was called something else and this ability was only available via slapt-get at the command line so that newer users were more protected from a point and click mistake but man page readers could take advantage of it? Perhaps even print a warning (imagining that slapt-get had a -L option like portmaster):

Code: Select all

# slapt-get -L *
...
===>>> Packages with no dependencies and not depended on
===>>> ***NOTE*** Some of these packages belong to the base system; be careful when removing them as their absence can break your system!
===>>> List here
...


Anyway, sorry to ramble. I have all of my questions answered. 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?

@Shador: thanks a ton... gosh I wish I knew shell scripts I've gotten library books several times and just don't get enough time to actually learn but I absolutely love the idea of being able to do what you and gapan did for me! I'm as advanced as doing some pipes and redirects... which actually does help out a ton!


Thanks all.


Best regards,
John

[Akuna]

Hi john,

Anyway, sorry to ramble. I have all of my questions answered.

Since you stated all your question were answered, and you quite profusely thanked Shador for helping you out with his script, that is actually why the conversation ended up here. So why did you then present the above thread in a rather slanted way in another distro forum? I quote you from there :

The devs and I went back and forth about it and then they just stopped responding. It basically went like this:
- Them: Salix doesn't tell you what orphan deps are (unlike Zenwalk) because too many users will see some orphan dep like 'base_aaa' and remove it thinking they don't need it. Also, it allows for advanced usage: you manipulate your machine's packages and nothing else.
- Me: so how can I find orphan packages?
- Them: someone provided a shell script that coudl kind of do it (with sed or gawk perhaps)
- 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.

The conversation kind of ended then...

That was kind of not very nice...

Tsk... tsk...

Could it be that it's just the name 'orphan' that's the issue with how you think of netpkg? What if it was called something else and this ability was only available via slapt-get at the command line so that newer users were more protected from a point and click mistake but man page readers could take advantage of it? Perhaps even print a warning (imagining that slapt-get had a -L option like portmaster):

Code: Select all

# slapt-get -L *
...
===>>> Packages with no dependencies and not depended on
===>>> ***NOTE*** Some of these packages belong to the base system; be careful when removing them as their absence can break your system!
===>>> List here
...


This is kind of an interesting suggestion.... although I hope you realize that it should be addressed directly to the maintainer of slapt-get if you hope for something concrete to come out of it? Unless we should be blamed for not passing on your messages as well?

=> http://www.jaos.org/

Regards,

Pierrick

[jwhendy]

Hi,


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.

5) Summary
-- 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?

John

[Akuna]

What do you think about my response?

John

I think that many words will not make for a justification.

If you are free to not agree with our distro policy, and that is your privilege, it is also our privilege to not see things your way without necessarily being bitched about it in some other distro's forum especially after taking the time to help you out in a very personal way the way you have been in this thread.

This is Linux... in other words, community members are active members not just consumers. Nothing prevented you from making a Salix wiki article out of this thread & this script so that it could have been useful for other power users that wanted to remove 'orphans' in a thoughtful & deliberate way from their system. That would have been the high road.

I think that Gapan's remark about not offering a point & click system that can be potentially harmful is very wise. Power users who know what they are doing are not rebutted by shell scripts. That is the full power of choice and thankfully choice is not limited by mere GUI utilities.

Regards,

Pierrick

PS: you can still redeem yourself by making that wiki article, I'm sure it would be very useful to other folks who share your concern. Plus that will be your way to contribute to the only Slackware based distro who offers a 64-bit solution that is, after all, quite close to your wish list.

[jwhendy]

Objectively, what is wrong with my summary, though?

The devs and I went back and forth about it and then they just stopped responding. It basically went like this:
- Them: Salix doesn't tell you what orphan deps are (unlike Zenwalk) because too many users will see some orphan dep like 'base_aaa' and remove it thinking they don't need it. Also, it allows for advanced usage: you manipulate your machine's packages and nothing else.
- Me: so how can I find orphan packages?
- Them: someone provided a shell script that coudl kind of do it (with sed or gawk perhaps)
- 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.

The conversation kind of ended then...

Your only point of complaint was stating (on behalf of gapan and Shador since you weren't even in the topic at the time) that I had posted 'all my questions are answered' and thanked Shador.

How is the above a 'slanted' presentation? Read through the posts and you will find that my report of the transpiring conversation is true to form.

Per your own definition of Linux, I'm free to state that I don't like one distribution. This is exactly what I did. I prefer Netpkg to slapt-get and I expressed that I did not want to migrate to Salix for that reason. I also accurately represented the Salix team's view of this fact: "slapt-get is adequate and we don't see any reason to switch from it. Use this script for what you want."

I've been above board on this present topic about my views... so why is an issue if I post them elsewhere?

I specifically remember this topic and remember being surprised that no one responded back at all about it. I guess I don't see what got you so upset... That I posted about Salix in ZW forums and they weren't positive?

John

P.S. I'll contemplate the wiki. I won't consider that a requisite for 'redeeming myself', though. I have searched before for slapt-get best practices and not found anything mind-blowing about how to get around its limitations.

P.P.S. You have not commented on what I would consider an obvious illustration here:
-- Salix has created dependency information for packages
-- Salix considers it great to be able to use this information to automatically install dependencies via built-in-functionality if the user wants to do so
-- Salix does not provide a method to remove those same automatically installed dependencies if they are not required by something else if the user wants to do so
-- Why am I considered crazy or slanderous for pointing this out? Salix is the group who proposed to improve Slackware with dep info... not me! I simply asked why it could not be used for both installation and removal and the reasons I got did not seem logically consistent...

P.P.P.S. I will take to heart the overall notice that complaining does not get me anything. You are correct. My complaining mainly stems from being dissatisfied with most distros I try in at least some manner and not having the time (married + 1.5yr old daughter) to just 'make a new distro' or learn everything that Linux has to offer. I love simple. I love a high powered package manager that lets me do what I want but doesn't force me to do what I don't want (manually track deps). I love stable. I want 64bit and actually need it for CAD at work as well as needing 32bit for Lotus Notes. My frustration and perhaps the vibe you pick up is not finding options for making this all happen.

As a last point of supporting my position: I was 'proactive' as far as suggesting what I think are some pretty good ways to make Salix even better. What better place to post than to some of the devs themselves about something like the equivalent to 'slapt-get -L' or something else?

You thought it was a reasonable idea and pointed me to the slapt-get maintainer. Why couldn't they have responded back with something like 'good idea, we'll think about that'? Instead... nothing. Which is exactly what turned me off about this thread in the first place. It just felt like 'ok, done with this guy and his questions.' I think my points were valid and proposed some tangible suggestions... and then they were not responded to.