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.
adding the PRGNAM , ...all scripts go to build inside UNIQ SUBDIRECTORY , .. this is nice , because can start at time all scripts that you want , no problems all go to their subdirectories
2 - after pkg creation , simply
Code:
rm -Rf $TMP &>/dev/null
NO MORE TRASH IN /tmp ,after package compilations....no danger because TMP are a uniq subdirectory and no delete the other works in process.
Well, you could argue that a successful build should remove the working files when it's complete. A failed build, on the other hand, should leave the files in place so that you can see how the build failed.
Well, you could argue that a successful build should remove the working files when it's complete. A failed build, on the other hand, should leave the files in place so that you can see how the build failed.
when make dirs all point to pepe ...pecause PRGNAM is unique per script
rm $TMP then remove /tmp/SBo/pepe subdirectory ...
___________________________
I have entirely system scripts build ,similar to sbo , but my scripts grep ever the most new version on project pages , and try to compile it.
One gui application , start when system starts , .. run scripts , and when see new versions , gui appears with new pacakges to build... that system is developed for slackware based distro , but some things can go SBo easy if want.
No, you didn't understand him, he said that it is useful to remove the files ONLY if the build is successful.
And I disagree with you, I don't want my packages deleted even if they were successful.
Take wine for example, it takes forever for it to build, if the script removes it, I can't even make a backup for later uses without modifying the script.
The better approach is for you to clean /tmp acording to your needs.
No, you didn't understand him, he said that it is useful to remove the files ONLY if the build is successful.
And I disagree with you, I don't want my packages deleted even if they were successful.
Take wine for example, it takes forever for it to build, if the script removes it, I can't even make a backup for later uses without modifying the script.
The better approach is for you to clean /tmp acording to your needs.
NO you no understand ... final package *.tgz goes under /tmp/*.tgz NEVER UNDER SAME FOLDER OF COMPILATION ..
Its very easy to understand..
ok , test that little modified ... crunch , i try this because little process , around only 20 seconds to pkg creation.
TEST , anr return to say something ...
Code:
#!/bin/sh
# Slackware build script for crunch
# Copyright 2013-2014 Vladimir Yatsemirski <7catssmile@gmail.com>
# All rights reserved.
#
# Redistribution and use of this script, with or without modification, is
# permitted provided that the following conditions are met:
#
# 1. Redistributions of this script must retain the above copyright
# notice, this list of conditions and the following disclaimer.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS OR IMPLIED
# WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
# EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
# OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
# ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
PRGNAM=crunch
VERSION=${VERSION:-3.6}
BUILD=${BUILD:-1}
TAG=${TAG:-_SBo}
if [ -z "$ARCH" ]; then
case "$( uname -m )" in
i?86) ARCH=i486 ;;
arm*) ARCH=arm ;;
*) ARCH=$( uname -m ) ;;
esac
fi
CWD=$(pwd)
# Modified TMP
TMP=${TMP:-/tmp/SBo/$PRGNAM}
PKG=$TMP/package-$PRGNAM
OUTPUT=${OUTPUT:-/tmp}
if [ "$ARCH" = "i486" ]; then
SLKCFLAGS="-O2 -march=i486 -mtune=i686"
LIBDIRSUFFIX=""
elif [ "$ARCH" = "i686" ]; then
SLKCFLAGS="-O2 -march=i686 -mtune=i686"
LIBDIRSUFFIX=""
elif [ "$ARCH" = "x86_64" ]; then
SLKCFLAGS="-O2 -fPIC"
LIBDIRSUFFIX="64"
else
SLKCFLAGS="-O2"
LIBDIRSUFFIX=""
fi
set -e
rm -rf $PKG
mkdir -p $TMP $PKG $OUTPUT
cd $TMP
rm -rf $PRGNAM-$VERSION
tar xvf $CWD/$PRGNAM-$VERSION.tgz
cd $PRGNAM-$VERSION
chown -R root:root .
find -L . \
\( -perm 777 -o -perm 775 -o -perm 750 -o -perm 711 -o -perm 555 \
-o -perm 511 \) -exec chmod 755 {} \; -o \
\( -perm 666 -o -perm 664 -o -perm 640 -o -perm 600 -o -perm 444 \
-o -perm 440 -o -perm 400 \) -exec chmod 644 {} \;
make
make install PREFIX=$PKG/usr MANDIR=$\(PREFIX\)/man/man1 DOCDIR=$\(PREFIX\)/doc/$PRGNAM-$VERSION
find $PKG -print0 | xargs -0 file | grep -e "executable" -e "shared object" | grep ELF \
| cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null || true
find $PKG/usr/man -type f -exec gzip -9 {} \;
for i in $( find $PKG/usr/man -type l ) ; do ln -s $( readlink $i ).gz $i.gz ; rm $i ; done
mkdir -p $PKG/usr/doc/$PRGNAM-$VERSION
cat $CWD/$PRGNAM.SlackBuild > $PKG/usr/doc/$PRGNAM-$VERSION/$PRGNAM.SlackBuild
mkdir -p $PKG/install
cat $CWD/slack-desc > $PKG/install/slack-desc
cd $PKG
/sbin/makepkg -l y -c n $OUTPUT/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.${PKGTYPE:-tgz}
# Clean here
rm -rf $TMP &>/dev/null
USUARIONUEVO, You didn't add anything useful or necessary; nor should you force your opinon onto others. There are some Slackbuild scripts that do add different directory locations, or an option to delete the source and package directory at the end. However, this is more complexity that is strictly needed, and you have not provided a compelling reason for your modification.
Currently, when each SBo script runs, it deletes any old package directories, if they exist, and recreates them. When the script finishes, we have the following:
Source files: /tmp/SBo/$PROGNAM-$VERSION
Package tree: /tmp/SBo/package-$PROGNAM
final package: /tmp/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.tgz
Nice and simple. K.I.S.S. You can easily create your own script for cron to periodically delete old entries in /tmp/SBo/ should you decide there is too much junk in /tmp.
NO you no understand ... final package *.tgz goes under /tmp/*.tgz NEVER UNDER SAME FOLDER OF COMPILATION ..
Its very easy to understand..
.. relax, you are right, it is easy
I have tmp mountet to tmpfs, so after a boot it's always clean,
that is where the build happens,
and configured sbopgk, to place finale packages into my home folder,
but you can also set the $OUTPUT variable to the place where you want to have your package, eg home, if you do not use sbopkg
so the build is in tmp and the final package where you want, this works already
This can be, should be, and in some cases actually is, handled by your build tool.
Quote:
Originally Posted by USUARIONUEVO
can start at time all scripts that you want
There are many more reasons than /tmp why this won't work. It needs some way of building dependencies independently, installing them independently, and storing the built packages independently. This requires locking with flock(1), and locking will lead straight to classic deadlocks. [1]
The alternative approach of maximising parallelism within each build (-jn, distcc) doesn't have all that hassle.
[1] That classic problem has a classic solution, so never say never
I did not intend to make any kind of personal attack on you GazL and to the extent that post #12 can be read as such I apologise unreservedly for leaving that interpretation open. Quite the reverse, I thought it was interesting that some of your use cases are the same as some of my use cases. Again, if you think my cack-handed attempt at levity is inappropriate then I apologise unreservedly and I hope you'll reconsider blanking your post.
Last edited by 55020; 08-31-2015 at 07:51 AM.
Reason: Struggling to say the right thing....
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.