The Myth of "Once you go Slack, you never go back"
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.
When you build a package with a Slackbuild script from SBo, the package should be built in /tmp/SBo unless there is a bug in the script and the final package is stored in /tmp.
Fixed that for you.
Oh man. We all know that anyone can make a mistake, and that a mistake can pass all checks incognito.
So, theoretically you are right.
Now practically, can you give one single example of a package not built in /tmp/SBo? Did you report that case?
Many of us heard this:
"Once you go Slack, you never go back"
Is Slack a myth?
Various times I must say, that I had troubles with installing Slack on a recent hardware.
My first Linux was Slack and I learned Debian at school.
Maybe pitty that I used more of Debian rather than Slack.
I turned to Ubuntu, Debian,... Gentoo, and too little of Slack.
Why Slack is still being a Myth compared to Ubuntu and Debian?
Regards
Why Slackers don't ask such questions in the Debian forum?
Oh man. We all know that anyone can make a mistake, and that a mistake can pass all checks incognito.
So, theoretically you are right.
Now practically, can you give one single example of a package not built in /tmp/SBo? Did you report that case?
well, can you guarantee that this never will happen?
anyway,
writing a build script as root is not a good idea
building packages as root is not a good idea
tools that require and force you to build packages as root are bad and broken by design.
for me,there is nothing to discuss about that, but of course I do not expect that everyone does agree with me about this
Oh man. We all know that anyone can make a mistake, and that a mistake can pass all checks incognito.
So, theoretically you are right.
Now practically, can you give one single example of a package not built in /tmp/SBo? Did you report that case?
No, I personally was not affected by such a bug, though I remember having read something like that on the SBo mailing list (I am to lazy to skim through the complete archive).
But I wasn't personally affected by the bugs in OpenSSL and Bash either, so does that mean that I shouldn't make sure that I will not be affected by those bugs?
The question remains: When it is possible to build all but a few packages (ffmpeg was named here) as non-privileged user, why is building as root still the default and why are the possible consequences of errors that every human can make downplayed with statements like "If you don't trust us GTFO!"?
Last edited by TobiSGD; 01-26-2015 at 12:28 PM.
Reason: fixed typo
fmpeg has a note the you have to run 'in a real root shell ("su -")'
I am sure someone knows why, and I think a some documentation why this is the case in the info file would be an improvement.
the build I had a quick look in the internet say nothing about that.
If you don't want to build as root, many (probably most) packages will build under fakeroot, just fine. This is not officially supported by the SBo team but that doesn't mean it doesn't work.
Personally, I create many of the additional packages "by hand" and use an alternative makepkg that supports creating packages with root owned files, when run as a normal user.
Personally, I create many of the additional packages "by hand" and use an alternative makepkg that supports creating packages with root owned files, when run as a normal user.
I simply move chown root:root at the end, just before makepkg
Code:
cd $PKG || exit 1
su -c "chown -R root:root . ; /sbin/makepkg -l y -c n $OUTPUT/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.txz"
It works most of the time. Sure it wont work with packages that have to install binaries owned by system users/groups.
Looking at it objectively, having many different ways of building packages validates my point that extending the default install is inefficient process. And we have many different ways because automated tools like sbopkg run as root and cant be trusted. This is not a complain or bashing. This is the way Slackware works. Many can find it cool to have dozen ways to create a package. Many can trust sbopkg if they like to.
ffmpeg has a note the you have to run 'in a real root shell ("su -")'
I am sure someone knows why, and I think a some documentation why this is the case in the info file would be an improvement.
the build I had a quick look in the internet say nothing about that.
One reason for using 'su -" is the PATH.
As normal user
Without /usr/share/texmf/bin in the PATH, documentation may not build correctly, which results in a failure to build the package in the case of ffmpeg.
For a similar reason, building po4a will fail if not run as root, with root's PATH. I've put a warning about that in the README. About sbopkg the authors already warn users in the home page:
Code:
Please note that while sbopkg has performed well for many users, it is still in a
testing phase. Please do not use in a production environment and please use a separate
copy/mirror of SlackBuilds.org, or at least make a backup of any changes to your local copy/mirror
before using sbopkg.
But there isn't much that can be done to protect users who neglect to read a warning.
Last edited by Didier Spaier; 01-26-2015 at 05:16 PM.
Reason: typos corrected
When you build a package with a Slackbuild script from SBo, the package is built in /tmp/SBo and the final package is stored in /tmp. There is no risk until you install the package
This is wrong. One typo in your SlackBuild, one variable that's not set, and your whole package build process happily spams your system. Since your SlackBuild is run as root, imagine what the opening line rm -rf $PKG with an unset PKG can do.
Building packages as root feels a lot like lead climbing. It's fun while you don't make too many mistakes, and some mistakes can hurt badly.
This is wrong. One typo in your SlackBuild, one variable that's not set, and your whole package build process happily spams your system.
I would like to draw a distinction between Slackbuilds from a trusted source like Slackbuilds.org, where there is a strict checking process in place, and building your own Slackbuilds, as you do. Quite naturally, when developing your own , you need to take precautions, such as building on a dedicated development box or within a virtual machine or using some alternative environment.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
