Introducing StripSlack, a minimal configuration of Slackware
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Also, fully tracing the Salix dependency files begins to move the system towards the heavier side, which, while not exactly a problem, is somewhat counter to the exercise at hand.
Right, because the Salix dep files are going to compensate for every dependency in every scenario. So there could possibly extra dependencies included that are not exactly required for this application.
Do you think it's going too far using the file-search? I could also easily bundle this into a single script, perhaps even improving performance some as well as reducing system load.
I have a very pragmatic suggestion. Perform an actual StripSlack installation, and test your scripts there.
I think this little project has reached a point where the next logical step is thinking more in depth about the system's coherence, e. g. dependencies.
So far, I've been using the little script depcheck.sh for this task, but it's rather crude. I didn't create it from scratch, but actually took the inspiration from the first of the three scripts on this page.
I'm a bit undecided about this subject, so I guess I'm open for suggestions and/or contributions for depcheck.sh.
if you want detailed info about binary dependencies on you system this is your best option.
it gives you much better and precise info than ldd, tells you not just what a file needs but also who needs a file and through working with a cache is very very fast,
just read throuhg the doc, its not that much
the last version is a bit old (for me) but works ok,
I made huge changes and some improvements since then in the hg repo if you want I can make in intermediate release the next days. (the repo is not always stable)
After quite some more fiddling, I really begin to wonder if this little project is worth the hassle. Hunting down dependencies and writing the according tagfiles takes hours if not days. And whatever I choose, I always seem to end up with some missing bit here and there. Performing ldd on all the binaries in the PATH allows me to find something vaguely coherent. But as soon as I dig deeper and do the same check on all the installed system libraries, there's always one more missing bit.
My conclusion for now: future server installations will be performed as usual, with only the E, KDE{I}, XAP and XFCE groups left out.
There are already quite a few tools, fwiw sbbdep is the only one that gets four and a half stars from me. (I never give anything five stars )
But there's a "false negative" problem here. ld.so dependencies are not the only ones to worry about. There are a lot more (python, perl...) that are really hard to detect. Also plenty of stuff uses dlopen, and again you are not going to catch those. If you solved the false negative problem, basically you would reconstruct (or at least document) the whole of Slackware. This problem needs a human curator.
Every false negative problem also has a "false positive" problem. The thing I *HATE* about automatic dependency resolution is that it is not a problem to have a few executables on your system that say 'not found' when you do 'ldd', if you never run them. And if you do run them, they will tell you what they need. This problem needs a human curator.
There's another thing too, which I think of as the 'libwnck' problem. *All* the packages in Slackware that use libwnck are in xfce/. So why isn't libwnck in xfce/? Because other non-xfce things *outside* Slackware (in SBo) use libwnck. So l/ is the right place for libwnck. You could do a cluster analysis to decide categories based on actual dependencies, but that's an NP-complete problem. So this problem needs a human curator.
So it all needs a human curator. Niki's conclusion is basically right. We already have some human curators. Their names are volkerdi and gapan and kikinovak and I think they are already doing a damn fine job. Four and a half stars from me
@a4z
Very nice, thanks for the heads up. I didn't know about sbbdep. I will definitely be turning my attention to using that for my needs in the future. Unless there's a request for me to carry my version of the deps script further, I will put it to rest for now (other than kikinovak's suggestion to test it on a StripSlack install). I'm not looking to duplicate other efforts; I have an aversion to ldd usage, especially scripted, which piqued my interest here.
Cheers
EDIT:
Btw, after testing sbbdep, I'm pleased to find such a useful tool. Very well done, a4z.
I read your announcement in your other thread about how you're switching your MLED project to CentOS.
If I wanted to continue working on StripSlack (mostly for personal use, not at the scope of MLED), how would you prefer I go about doing that? Would you prefer I clone your entire SlackWare repository? Copy the StripSlack files to a new repository?
Obviously, your support email address (at the top of the "README") wouldn't really be applicable anymore. I'm also concerned about giving you proper credit, since you never put any license or your name at the top of the shell scripts and tagfiles.
I read your announcement in your other thread about how you're switching your MLED project to CentOS.
If I wanted to continue working on StripSlack (mostly for personal use, not at the scope of MLED), how would you prefer I go about doing that? Would you prefer I clone your entire SlackWare repository? Copy the StripSlack files to a new repository?
Obviously, your support email address (at the top of the "README") wouldn't really be applicable anymore. I'm also concerned about giving you proper credit, since you never put any license or your name at the top of the shell scripts and tagfiles.
Hi,
Yes, just grab the whole Git tree, and then feel free to cannibalize anything as you wish. I don't mind about being given credit or not. Feel free to drink a beer to my health.
Yes, just grab the whole Git tree, and then feel free to cannibalize anything as you wish. I don't mind about being given credit or not. Feel free to drink a beer to my health.
Cheers,
Niki
Great, thanks a lot for your SlackWare work, and best of luck with the new project!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.