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 to see a choice when installing Slackware 13 amd 64 version of Grub or Lilo. I prefer grub. Come on Slack developers it can't be that hard to give us a choice.
M H
Click here to see the post LQ members have rated as the most helpful post in this thread.
I would like to see a choice when installing Slackware 13 amd 64 version of Grub or Lilo. I prefer grub. Come on Slack developers it can't be that hard to give us a choice.
M H
Interestingly, from what I can tell, Grub is in /extra for Slackware 13, but not for Slackware64_13.
I'm not a big Xfce user, but the Salix people have solved that problem. The Salix developers have provided full backwards compatibility of their system with the stock Slackware. That means packages in the Salix repository can be used in Slackware. The Salix people embrace a one-app-per-task system, but there are additional packages in their repository.
Although the Salix developers originally were part of the Zenwalk team, Salix is not a fork of Zenwalk. Salix uses Slackware as a base. The current version of Salix is 13.0.2a.
I'm not part of the Salix team. I tested Salix the past couple of days and I can recommend the system to others, both as a stand-alone system and as a repository of additional packages.
I don't know what the Salix developers plan for the future, but I welcome their graphical admin tools. Those tools will help non-technical users who prefer the Slackware design but are not fans of the command line.
I'd like to see the Salix developers approach Pat and perhaps see those graphical admin tools offered in the /extra branch. Perhaps they can convince Pat to move all of their Xfce apps into /extra. But at least all of the apps are available as a repository. All Slackers need do is configure their package manager repository list.
Quote:
I would like to see a choice when installing Slackware 13 amd 64 version of Grub or Lilo. I prefer grub. Come on Slack developers it can't be that hard to give us a choice.
I prefer grub too and so do many other regular Slackers. We all have been beating that drum for a few years now to no avail. The dev team and Pat do surprise folks now and then and grub might one day be an option. Not yet.
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 had a closer look and I think that I am a bit wrong.
seems to be OK to use threadsafe versions even if you do not use threads in an app (and don't want to pay the price for that) nowadays.
I am not a fan of this, but ok.
currently my other dist where I evaluate my builds is openSuse11.2
there the -mt version is a link to the non -mt named version.
so, if it is good practice today to use just the multi threaded version, it could be a good idea to add those symbolic links for backward compatibility for build scripts that explicit search for the -mt version.
or is this to old style?
but anyway, changing the seed through the jam files to the correct bjam call (use --layout=system instead of tagged) can't be to wrong.
suggestion:
this is my adaptation of the current boost build script
(I have changed as less as possible, maybe there could be done a few other changes like the ICU line cause icu seems to be auto detected, but this is not important at the moment for me)
Code:
#!/bin/sh
# removed Copyright info just for the post here
VERSION=1_41_0
BUILD=${BUILD:-1}
# Automatically determine the architecture we're building on:
if [ -z "$ARCH" ]; then
case "$( uname -m )" in
i?86) export ARCH=i486 ;;
arm*) export ARCH=arm ;;
# Unless $ARCH is already set, use uname -m for all other archs:
*) export ARCH=$( uname -m ) ;;
esac
fi
CWD=$(pwd)
TMP=${TMP:-/tmp}
PKG=$TMP/package-boost
ICU=${ICU:-no}
PKG_VERSION=$(echo $VERSION | tr _ .) # Leave this alone
if [ "$ARCH" = "i486" ]; then
SLKCFLAGS="-O2 -march=i486 -mtune=i686"
LIBDIRSUFFIX=""
elif [ "$ARCH" = "s390" ]; then
SLKCFLAGS="-O2"
LIBDIRSUFFIX=""
elif [ "$ARCH" = "x86_64" ]; then
SLKCFLAGS="-O2 -fPIC"
LIBDIRSUFFIX="64"
fi
rm -rf $PKG
mkdir -p $TMP $PKG
cd $TMP
rm -rf boost_$VERSION
tar xvf $CWD/boost_$VERSION.tar.?z* || exit 1
cd boost_$VERSION || exit 1
chown -R root:root .
find . \
\( -perm 777 -o -perm 775 -o -perm 711 -o -perm 555 -o -perm 511 \) \
-exec chmod 755 {} \; -o \
\( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \
-exec chmod 644 {} \;
# Apply Hotfixes from:
# http://svn.boost.org/trac/boost/wiki/ReleasePractices/HotFixes
#
# (none currently for this $VERSION)
# This is the python we build against:
PYTHON_VERSION=$(python -c 'import sys; print sys.version[:3]')
PYTHON_FLAGS="-sPYTHON_ROOT=/usr -sPYTHON_VERSION=$PYTHON_VERSION"
#build bjam, --prefix --libdir required?? does not bother so I leave it
./bootstrap.sh \
--prefix=$PKG/usr \
--libdir=$PKG/usr/lib${LIBDIRSUFFIX}
# Create build subdirectory
mkdir obj
#Create install dirs
mkdir -p $PKG/usr/{lib$LIBDIRSUFFIX,include}
# Next, build boost && install to DESTDIR using bjam
# since there is no pkg-config files ore something else that includes path infos
# build && install to DESTDIR should be ok
./bjam \
"-sNO_COMPRESSION=0" \
"-sZLIB_INCLUDE=/usr/include" \
"-sZLIB_LIBPATH=/usr/lib${LIBDIRSUFFIX}" \
"-sBZIP2_INCLUDE=/usr/include" \
"-sBZIP2_LIBPATH=/usr/lib${LIBDIRSUFFIX}" \
"-sEXPAT_INCLUDE=/usr/include" \
"-sEXPAT_LIBPATH=/usr/lib${LIBDIRSUFFIX}" \
--toolset=gcc \
--layout=system variant=release threading=multi link=shared \
--builddir=obj \
--prefix=$PKG/usr \
--libdir=$PKG/usr/lib${LIBDIRSUFFIX} \
--build-type=minimal \
$PYTHON_FLAGS \
stage -d+2 -q install
# TODO --build-type=minimal and stage, why?
#this is not required cause the libs are compiled -O3 and striped within install
#find $PKG | xargs file | grep -e "executable" -e "shared object" \
# | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null
#adding -mt links
( cd $PKG/usr/lib${LIBDIRSUFFIX}
for LIBLNK in $(ls *.so.${PKG_VERSION} ); do
BASE=$(basename ${LIBLNK} .so.${PKG_VERSION})
LNK_MT="$BASE-mt.so"
ln -sf $LIBLNK $LNK_MT
done
for STATICLIB in $(ls *.a ); do
BASE=$(basename ${STATICLIB} .a)
LNK_MT="${BASE}-mt.a"
ln -sf $STATICLIB $LNK_MT
done
)
mkdir -p $PKG/usr/doc/boost-$PKG_VERSION
# Do not copy 44MB of developer 'doc/html' into our package...
cp -a LICENSE_1_0.txt $PKG/usr/doc/boost-$PKG_VERSION
find $PKG/usr/doc -type f -exec chmod 0644 {} \;
mkdir -p $PKG/install
cat $CWD/slack-desc > $PKG/install/slack-desc
cd $PKG
/sbin/makepkg -l y -c n /tmp/boost-$PKG_VERSION-$ARCH-$BUILD.txz
changes:
using bootstrap for creating bjam
removing seeding throug jam files via passing flags to bjam
adding -mt links for installation so existing builds searching -mt libs will not fail
Last edited by a4z; 12-27-2009 at 03:53 AM.
Reason: adding info
I'm not a big Xfce user, but the Salix people have solved that problem. The Salix developers have provided full backwards compatibility of their system with the stock Slackware. That means packages in the Salix repository can be used in Slackware. The Salix people embrace a one-app-per-task system, but there are additional packages in their repository.
So does rworkman http://www.rlworkman.net/pkgs/
If it would be me id prefer getting packages from a trustworthy source rather than using another distribution.
Quote:
Originally Posted by Woodsman
I prefer grub too and so do many other regular Slackers. We all have been beating that drum for a few years now to no avail. The dev team and Pat do surprise folks now and then and grub might one day be an option. Not yet.
GRUB is still alpha software. All versions of it. But im wondering how is Pat gonna react to LILO not being able to boot larger (more recent) kernels.
My guess is that hes gonna prefer to edit liloconfig than resorting to GRUB...
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.
I agree with this and I'd also like to see RSS feeds for the changelogs. I'm sure I've seen RSS feeds elsewhere, but they've been out of date.
With regards to LILO and GRUB, I use GRUB on one of my machines because I like being able to have spaces in titles. On my other machine, I use LILO because I don't need that.
Anyway, I would also like Slackware ported to other architectures, and something like KDEMod. GRUB will be great. Personally, I think it's way better than LILO.
I've seen GRUB2 compiled for Slackware, and I was using it until recently, but I couldn't figure out an alternative to the "vga=" option. It said to load some module, I did what it said, but no luck.
And I would really like a bit more open development. I am willing to contribute a lot of things.
I would also like sbopkg in the default installation. Slapt-get is also a pretty good tool, however I don't see a chance of it being included.
Another great thing would be another mode for the install (let's say "Minimal"), which installs only the things required for KDE.
Dependency information by default would be awesome. There are a lot of tools for that already, like depfinder and requiredbuilder. The second one is slow and outdated, although it usually provides more accurate information because it's python dependency tracking. This can be easily implemented in depfinder, too.
Another thing would be Firefox and Thunderbird cmpiled against xulrunner.
If you want a LiveCD Slackware-based distribution with NetworkManager and GNOME, check this out: http://linvo.org; currently, it only has a KDE version, but I'm soon releasing a version with GNOME, NetworkManager, and initng instead of sysvinit, based on Slackware 13.0; If someone is willing to test the release candidate, PM me It also includes OpenOffice, Empathy, Skype, Exaile, Totem, and all the GStreamer codecs, including gst-ffmpeg, and other apps.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.