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 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.
From what ive seen from exploring the Slackware sources tree quite a lot of times, the packages are built on a stock Slackware system. By that i mean that when a package like MPlayer has its configure options to be autoconfigured, it will pick up every dependency it can find in Slackware and samba or aalib are some of them.
From my point of view for example linking to aalib is as pointless as samba. Maybe even more.
But thats mostly cause of MPlayer, not Slackware in a sense. Most packages dont work that way for the most part.
But when the package is able to autoconfigure itself its very easy to build a package for it without messing with configure much.
Click here to see the post LQ members have rated as the most helpful post in this thread.
Slackware rc-init scripts compatible with (d)ash shell
Quote:
Originally Posted by tuxdev
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.
..and on that note, I decided to find out. I linked /bin/sh to /bin/dash on my system and all hell broke loose; the system wouldn't even shut down.
As it turns out, a number of Slackware (13.0) rc-init scripts are not POSIX compatible, including rc.inet1, rc.inet1.conf, rc.S, rc.wireless, and maybe a few more. Also, a few of UDEV's tools/scripts in /lib/udev, some other shell startup.sh scripts in /etc/profile.d, one script in /usr/share/mc, were also written for Bash specifically.
As you (people in general) may know, calling Bash by /bin/sh starts it in "POSIX" mode, but it is not actually fully POSIX compliant; it still allows some bashisms.
I went through ALL of the init scripts a person would normally use, and the others mentioned above, and fixed them all up so they're (more?) POSIX compatible and updated a couple things in most of them, such as changing backticks to $() and [[ ... ]] to [ ... ] and replacing double-negative tests
like [ ! "$somevar" = "" ] with saner things.
/etc/profile got some small changes, and in the comments in that file, I put a few notes about $HOME/.profile which ultimately may not be important, but at this time, I'm not exactly sure how/when the environment variable $SHELL is supposed to get set, and /etc/profile doesn't correctly detect $SHELL unless the value is exported from $HOME/.profile, all of which leaves the user with a crappy shell prompt.
Also, there's some zsh code in /etc/profile which dash doesn't enjoy, so that's commented out. Finally, bash_completion.sh causes dash problems, so in /etc/profile, all extra scripts EXCEPT that one, are sourced when $SHELL='/bin/dash'.
Likely there are lots more things here and there which would need to be fixed; what I've done is not all-inclusive, and probably not perfect. Plus, other peoples' systems will have scripts and things that mine doesn't, which may need repairs to work with (d)ash shell as /bin/sh. But, my machine currently works really nice with dash as /bin/sh -- kernel can be built, no problems, bootup is a little speedier for those who care about that, and there's a noticeable difference in general speed of the shell. And, Dash is 1/7th the size of Bash.
Here's a folder of all my init scripts including those extras mentioned above; some have little or no changes, but all have been checked and repaired as needed. Pay particular attention to rc.inet1.conf because the format of the config entries has changed
NOTE: This is a tar.gz archive. I renamed it to .txt so it would upload. The md5sum remained the same regardless of the .txt extension:
PS - comments on this (if there are any) would probably be best in a separate thread, linked to this post, so we don't derail this thread completely. I posted this here because it was in context with the previous few posts. So, either start a new thread for comments, or contact me and I will do so.
Cheers!
Sasha
PS - A couple of the init scripts, like rc.local, are from my own system, so they aren't stock! Don't just blindly replace stuff -- check them out first if you want to try this out.
PPS - if you use XDM login, then /etc/X11/xdm/Xsession needs some small mods for it to source the /etc/profile and ~/.profile files under dash influence; the mods are pretty straight forward, but if you want, I can post that file too. In fact, I think I will start another thread on this after all. Just not right this minute
Last edited by GrapefruiTgirl; 12-25-2009 at 02:54 PM.
Update website documentation explaining how to use slackware tools and how to keep an up-to-date version of slackware. A large FAQ with things like multilib issues, 64 Bit specific things etc.
Updated Slackbook with not only tiny bash/mail/etc manual. I'd prefer some sort of Slackware Bible (like Ubuntu Bible) or smth. One book of slackbook + slackbasics + slackersbible + more. Now everything is thrown around in lots of places (those previously mentioned books, Alien Bob's dokuwiki, slackwiki and more, more, more places).
I'd really love to see some centralized documentation as well. I've always admired FreeBSD's Handbook and have even considered giving FreeBSD another shot just because of that (I had a few problems with the actual OS, though, so I'm sticking with Linux). Also, with all these sources split apart, some of them become outdated and conflict with more current sources. A single, large project to produce an amazing Slackware Linux Manual would be outstanding. Make it rolling release (sections are updated by contributors as soon as they can be) like the FreeBSD Handbook and it'll stay updated easier. Lots of BSDers complain about Linux's lack of centralization in general, and while that can be a good thing, certain cases, especially documentation, suffer from such a system. I know I pointed out a lot about BSD, but in my opinion they do certain things right, and we can learn from that.
Slackbook 3.0 has been taking forever and should have been out about six months ago. I hope the new release is at least up to date!
I linked /bin/sh to /bin/dash on my system and all hell broke loose; the system wouldn't even shut down.
I went through ALL of the init scripts a person would normally use, and the others mentioned above, and fixed them all up so they're (more?) POSIX compatible and updated a couple things in most of them, such as changing backticks to $() and [[ ... ]] to [ ... ] and replacing double-negative tests
like [ ! "$somevar" = "" ] with saner things.
Do not code based on output from an interpreter go back to the standard and then test based on that, if your test fails then the interpreter is at fault not the code.
BTW there is no '/bin/dash' on my Slackware system, where did yours come from?
Yes, technically they are the same, but `` is rather deprecated, and becomes complicated and ugly to use when nested and/or in longer or more complex lines of shell code; multiple instances need to be escaped, etc..
Quote:
I see the same mistake made by web developers.
Which "mistake" is that?
Quote:
Do not code based on output from an interpreter go back to the standard and then test based on that, if your test fails then the interpreter is at fault not the code.
I'm not sure what you're referring to in the above; if you're talking about some/any of the editing I've done to my init scripts, then to be clear: I repaired them so they would be POSIX compliant (that's the standard), which they were not; this makes the code at fault, not the interpreter. Bash is far from POSIX compliant, despite its many great features.
Quote:
BTW there is no '/bin/dash' on my Slackware system, where did yours come from?
I downloaded it from Sourceforge or freshmeat or wherever its home page is, and built & installed it.
I'd really love to see some centralized documentation as well.
Slackbook 3.0 has been taking forever and should have been out about six months ago. I hope the new release is at least up to date!
Here is a centrally located source but it appears that it is not maintained as it should be.....
I'm not sure what you're referring to in the above;
When web designers code their stuff they rarely use the standards themselves while coding, rather they use their favorite web browser to check the code for compliance assuming that it is a correct implementation.
The correct method is to code to the standards themselves and then test the interpreter against the correct code and if it fails then the interpreter is at fault and not the code.
'EDIT' When a fault is detected with the interpreter you should (A) file a bug report with the vendor and (B) document your code at the point you put in the hack to get around the bug. 'EDIT'
PS nowhere in the standard is `` listed as deprecated, unless such a statement actually exists then you should not make the assumption that it is so.
Last edited by wildwizard; 12-25-2009 at 03:01 AM.
When web designers code their stuff they rarely use the standards themselves while coding, rather they use their favorite web browser to check the code for compliance assuming that it is a correct implementation.
The correct method is to code to the standards themselves and then test the interpreter against the correct code and if it fails then the interpreter is at fault and not the code.
'EDIT' When a fault is detected with the interpreter you should (A) file a bug report with the vendor and (B) document your code at the point you put in the hack to get around the bug. 'EDIT'
PS nowhere in the standard is `` listed as deprecated, unless such a statement actually exists then you should not make the assumption that it is so.
I'm not going to further derail this thread (after this post) to argue about the POSIX standard with you. However, evidently I need to clarify for you that I replaced backticks with $() in my init scripts for reasons NOT having to do with the POSIX standard-- rather, for the reasons I indicated above, including simplicity of use, and readability...
The OTHER changes I made to the scripts, were done so that the scripts would be POSIX compliant.
I don't code based on what a given interpreter "likes". However, I will code according to a standard for some things; in this case, the standard is POSIX. Dash happens to be POSIX compliant, and does not accept any "bashisms", so I use Dash to test the code for compliance. If it doesn't comply, there's something wrong with the code.
Nowhere did I write that `` are not POSIX compliant, nor did I write that POSIX says `` is deprcated.
If you want to say I made an assumption about `` being deprecated, then so be it. That's what I assume, based on among others, this link here: http://mywiki.wooledge.org/BashFAQ/082
..where the last line reads:
Quote:
The only time backticks are preferred is when writing code for the oldest Bourne shells, which do not know about $().
So yes, to me, that means 'deprecated', and if there comes a time when those 'oldest Bourne shells' are completely obsoleted, then `` will be officially 'deprecated'.
a note to slackware-currents boost libraries
(I put this here cause I don't know where else to post this message, sory if this is OT in here)
I am verry happy to see that the boost libaries got the version number appended!
but I miss the single-multi threaded versions, in the current package only one is included (without -mt).
so all my projects that use the -mt version didn't rebuild
so I had to fix this (quickly) yesterday evening and I did the following
this is not a perfect build, but I don't use the Graph library ore ICU (regex lib) and --without-mpi could also be passed as an option to bjam
but it builds the libs in non mt and an -mt version + version number appended
and so far, my projects using boost build and run correct and I have not noticed any side problems in existing slackware packages I use
but I do not know which slack packages do link against boost, so it could be that I need to rebuild some software.
a4z -- thanks for posting that boost info. I'm fairly sure someone will find it helpful. I myself have found building against boost to be a pain in the a$$ more often than not. It's still tricky sometimes getting sourcecode to even *find* the boost libs, let alone build against them.
a note to slackware-currents boost libraries
(I put this here cause I don't know where else to post this message, sory if this is OT in here)
I am verry happy to see that the boost libaries got the version number appended!
but I miss the single-multi threaded versions, in the current package only one is included (without -mt).
so all my projects that use the -mt version didn't rebuild
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.