What features/changes would you like to see in future 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.
I tried out tracepkg yesterday. It can build a database of package dependencies for you, without doing anything else -similar to what the old slackdeptrack does(written in perl). But tracepkg is written in pure bash so it easier(for me) to hack. I doubt that I'd use it to manage packages, but it certainly provides nice information -especially when it lists needed libraries which are mising from your system.
I tried out tracepkg yesterday. It can build a database of package dependencies for you, without doing anything else -similar to what the old slackdeptrack does(written in perl). But tracepkg is written in pure bash so it easier(for me) to hack. I doubt that I'd use it to manage packages, but it certainly provides nice information -especially when it lists needed libraries which are mising from your system.
That sounds useful to me as well. The reason I thought it would go against the Slackware philosophies is because of the description in the link given above:
Quote:
tracepkg is an auxiliary tool for slackware administrators:
tracepkg automates the installation/remotion/upgrade of slackware
tgz's, removing automatically a package with all its unshared
dependencies and building a database for all installed and missing
dependencies needed by a tgz.
I think Slackers should go to this tracepkg link first instead. As you mentioned, tracepkg just lists the dependencies, which is useful. It does not automatically remove and install dependencies.
Quote:
Originally Posted by http://www.slacky.eu/~absinthe
tracepkg is a bash script collection made to help Slackware administrators with the management of tgzs. It scans tgzs stored in the /var/log/packages directory and finds all their binary dependencies using ldd. tracepkg searches dependencies into the other installed tgzs. If a dependency is found, the related tgz is stored inside the /var/log/dependencies directory, instead, if the dependency is not found, the missing file is stored inside the /var/log/missing directory. Of course tracepkg doesn't substitute the administrator, as in the slackware philosophy (or in a sort of).tracepkg is NOT another tool for dependency resolution, it's just a tool that helps the administrator.
It will remove unshared dependencies if used to actually manage packages. This is mentioned in the man-page.
I have long used slackdeptrack -I like the summarized information about packages depedndencies. It is especially useful for cutting down the size of your installation. Of course information on binary dependencies and suggested programs is not generated.
In looking through the code, I found a couple of ideas which are going to be useful for src2pkg. src2pkg already has routines which do much the same as the data-base functions of tracepkg, except it just reports the dependencies of the package being built.
Most Slackers get over-sensitive whenever the word 'dependency' comes up -some people even say that SLackware packages 'have no dependencies' -which is, of course, rubbish. It's also incorrect to say that Slackware has no 'dependency hell'. Any given package can have unmet dependencies -it's just that slackware has no tools which try to resolve those dependencies. The 'hell' is what results from trying to programatically resolve them. It is still a bit of hell to identify and track them down on your own.
The dependency information produced by slackdeptrack, tracepkg and src2pkg is all produced 'after the fact'. It doesn't help you to identify or resolve those dependencies the first time you build a package. But it provides time-saving information for the next time you build that package. And, the cross-referenced information is often surprising and helpful in other ways -especially if you use a partial or highly customized installation.
I would like some packages to be compiled without needing so many (Generally unneccesary) dependancies.
An example of this would be mplayer requiring samba. People playing movies via a windows network share are the exception rather than the rule, and so it would be nice for those of us who dont want to do a full install to not require it.
And yes, I am aware we can go and compile it ourselves and grab the slackbuild, but I think it would make more sense to cater to general usage rather than exceptions.
I've recently been using the Dash shell for some testing, and since discovering the notable speed difference of it over Bash (and if you're concerned, it's fairly smaller than Bash too), I've been using Dash more regularly.
Given that there are generally more than one of most applications included with Slack, why not include an extra shell as well? A smaller, lighter one may appeal to a lot of people, even if they don't realize it yet.
I've recently been using the Dash shell for some testing, and since discovering the notable speed difference of it over Bash (and if you're concerned, it's fairly smaller than Bash too), I've been using Dash more regularly.
Given that there are generally more than one of most applications included with Slack, why not include an extra shell as well? A smaller, lighter one may appeal to a lot of people, even if they don't realize it yet.
Without addressing the pros and cons of dash, there is a great alternative already included - ksh.
Since all the init scripts claim POSIX compatibility (#!/bin/sh), there's some advantage to moving ash from ap/ into a/ and using it as /bin/sh. If any of the scripts break, then they obviously weren't POSIX and really need fixing anyway.
Slackware seems to me to be pretty complete, probably a Larger and more extensive slackbook would come handy...
BRGDS
Alex
Agreed. Slackware is a complete distro.
Further refinement of the documentation is an on-going process. The Slackbook is excellent.
I am very happy with the direction that -current is going in.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.