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.

..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:

The archive has been moved to:
http://www.linuxquestions.org/questi...k-13.0-778084/

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

Don't change anything about Slackware.

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.

Thanks.

1 members found this post helpful.

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!

http://www.opengroup.org/onlinepubs/...cu_chap02.html

$() and `` are the same

I see the same mistake made by web developers.

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..

Which "mistake" is that?
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.
I downloaded it from Sourceforge or freshmeat or wherever its home page is, and built & installed it.

Sasha

Here is a centrally located source but it appears that it is not maintained as it should be.....

Maybe the Slackbook should be hosted on the wiki?

http://slackwiki.org/Main_Page

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:

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'.

Anyhow, Happy Holidays

Sasha

Happy Holidays to you as well, Sasha

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


cd boost_$VERSION

./bootstrap.sh \
--prefix=$PKG/usr \
--libdir=$PKG/usr/lib${LIBDIRSUFFIX} \

#^^ build bjam

./bjam \
--prefix=$PKG/usr \
--libdir=$PKG/usr/lib${LIBDIRSUFFIX} \
--build-dir=zbuild \
--layout=tagged \
variant=release threading=single threading=multi link=shared \
-d+2 -q install

#^^ build and install boost libs


so, if any slackbuild scrip writer reading arround here,
please use this

--layout=tagged variant=release threading=single threading=multi link=shared

instead of seeding through jam files

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.

1 members found this post helpful.

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.

Cheers,
Sasha

Which packages might those be?
FWIW see http://www.linuxquestions.org/questi...00#post3797400 and rworkman's reply.

have not seen this, thanks

the -mt suffix is not just cosmetic, for me as a developer it makes sense.

if I write an app that does not need multi threading, locking calls are absolutely not needful.

and, there are a lot of other things

one example: typical CMake stuff

SET(Boost_USE_STATIC_LIBS OFF)
SET(Boost_USE_MULTITHREAD ON)
SET(Boost_ADDITIONAL_VERSIONS "1.36" "1.37" "1.38" "1.40" "1.41")
FIND_PACKAGE( Boost 1.39 COMPONENTS program_options thread unit_test_framework )


CMake will not find the boost libraries if they do not exist with the -mt suffix

slackware should not go its own way with boost.

again: the -mt suffix is not just cosmetic.

I'd like to see a more complete Xfce.
KDE4 has forced alot of us to switch, so I know I'm not alone.