That is why I build packages and put them in a repository for you to install. I take the risk of building your packages as root, and you take the risk of installing them as root.

4 members found this post helpful.

trust to SBo was never an issue, bad praxis, like building as root, was and is an issue.
why does this always drift into this direction?

the advice, open the script, comment out, ... why do so if there is a tool that helps you avoiding this?
why make it complicated if it can be simple.
fakeroot should be standard and tools should use it and become root only for installing
who wants to be root can continue be root, even during building....
others can live save
its just a win, normally you would not even need to think about this simple fact, how do you native englsih speakers say, no brainer?

well, I have my own fakeroot build, after the weekend not even this needs to be build as root anymore, and I will continue using sbopkg for these packages where writing my own scripts is to much work for re inventing the weel,
but I will still have the opinion that sbopkg is broken by design through running all as root, but possible this is a positive motivation for me to write something for me :-)

1 members found this post helpful.

The philosophy behind SlackBuilds.org (and by inheritance, sbopkg) was established after discussing the idea for the repository with Patrick.
The SBo philosophy is directly derived from Slackware's approach to building packages. We did not want to start a site that would grow popular and would offer SlackBuilds that would work different from Slackware's scripts. Patrick foresaw that people would come demanding that Slackware had to adjust its way of building packages because SlackBuilds.org would do it differnently and lots of users would have grown accustomed to it.
Precisely that is what some people in this thread are trying to accomplish. Pat's foresight was warranted.

Building as root is what Slackware does, and it is not going to change. Neither is it a bad practice.

<challenging>
Next question would be: why does Slackware not alias "rm" to "rm -i" like all those other distros, because of its inherent danger to delete large amounts of data without warning?
</challenging>

4 members found this post helpful.

You could have asked as well why are regular users allowed to run "dd"...

PS Maybe Slackware should ship a wrapper:
"This command is very dangerous! are you sure you want to use it? [N/y]
and if yes then:
"You are about to wipe out all data on this device! Do you really want to continue? [N/y]

But, actually you wrote something like that in usb2disk.sh!

Oh, that's just to tease you, I understand that the context is different

That's why I'm almost hardwired to type "\rm" instead of merely "rm".

And I very much appreciate that. Indeed I use many of your packages.

Perhaps people think I am making a mountain out of a mole hill in that I can just install fakeroot (and indeed I do) but there are too many places that assume actual root when they do not need to IMHO, sbopkg being one of them.

Anyway, I have said more than my share on this subject and pulled the thread very much in one direction, so I'll try and leave it be now. I don't want those behind SBo or anyone from the Slackware team thinking I am ungrateful as I am certainly not, nor would I want this to become one of those endless boring threads (like the systemd ones).

In summary, thanks to anyone who took the time to reply to me and no hard feelings if we disagree on this, as there are certainly none my side.

there seems to be some miss understanding,
script would not work or be different, they stay the same

it a question of the tool, no the script.
I can build all scripts, fakeroot
you call "fakeroot program.Slackbuild"
so what's the problem for the scritp? there is non. scripts stay identical.

I do and did not question the scripts, neither SBo, or any persons,

but I have the opinion that sbopkg is broken by design because it could call fakeroot program.Slackbuild.
and I think that people live dangerous if they develop/write scripts as root, but hey, if its not my machine they are working on ....
and that buildscripts have to be run as root is a myth that should be documented

I have already written that I am aware of the fact that not all people will have the same opinion as I, that's ok for me,
but please allow me to have the opinion that I find a tool broken that requires users to work as root even if its not required.
and please please allow me also the opinion that rm -i and dd sarcasm is not productive

1 members found this post helpful.

I could be a smartass and say, "Because Slackware is built by adults for adults," but that would be naughty.

As far as I know, Slackware is the most un-fooled-around-with and closest to Unix of any distribution (maybe there's another but I don't know that -- and really don't want to, either ). That's why I came to it and have not been tempted to look or go elsewhere.

I know that I've done it (once!) on a Unix box (my own, fortunately): rm -r * .bak in root (like, /, not /root there wasn't any such thing then). Whole system went bye-bye really, really quick. Oops. Took about two hours to restore from the release DC-600 tape cartridge and the back up tapes.

Never did it again, always look to see where I am and double-look at the rm command I've just typed ('cause I fumble-finger things).

Things that want to prompt me about whether I really want to do that just annoy the hell out me -- on of the many, many reasons that I won't allow Microsoft and the property (well, I do have Win7 in a virtual machine but that doesn't really count because I don't use it for anything that matters).

Bottom line is learn your craft and watch what the hell you're doing, eh?

2 members found this post helpful.

sbopkg, sbopkg, sbopkg ... (sigh) there are other tools, and at least one of them now supports nonroot building (and a vast number of other major improvements, and is almost a thousand lines of code smaller, but I don't want to evangelise ). sbopkg was a revelation of excellence for its time and its use case. It is still excellent for that use case, but personally I've moved on. For sbopkg to use fakeroot, the fix would be trivial. There is no need to change anything at SBo to enable that fix. Or with the right directories and permissions you could probably run your whole sbopkg session with 'fakeroot sbopkg' ... why not try that?

Otherwise: slackrepo-0.1.90-noarch-1_dbs.txz (sha256sum c27c7c9a4a42fa920f5c28401e0d507cddebd766143c682fa8ab848b1506218c)
It is new, and install mode has bugs that I am still fixing, but if you're not root, it won't screw up your whole system. If you're willing to wait a couple of weeks, there will even be up to date documentation and examples. And I want to say, thank you a4z for suggesting a really useful new feature.

a4z, if you think that supporting fakeroot is a valuable feature for sbopkg, then I would suggest mailing your suggestion to the developers: http://www.sbopkg.org/devel.php
Or better, write the patch that adds support for fakeroot and email them that patch.
Here is where you can create your request: https://code.google.com/p/sbopkg/issues/entry

1 members found this post helpful.

Been there ... done that ;-) Luckily not on a production server.

1 members found this post helpful.

Me too (the VMS equivalent).

Most people only do it once and are better for the experience. A few people never do it at all. Yesterday I was thinking about the man who taught me the word 'copacetic'; I found his obituary. It includes these words: "Any mistake he made would have had a major impact on many people's work, but he was not the sort of person who made mistakes". That is only one of the many reasons that I still remember and admire him.

Slackware is great for climbers and bikers. Same mindset.

Edit: and once you've grown a strong dislike of hospital food, you learn to be extra careful.

You'll have to use the --no-preserve-root option with rm if you want to wipe everything out. But how does rm delete itself?

let see

starting the script with a check if you are not root an fakeroot is available,
exit if you are not root and no fake root
exoprt /usr/bin/fakeroot ro FAKEROOT are not root and fake root exist
leave FAKEROOT empty if root
[I]put FAKEROOT in front of upgradepkg install new[/I]
edit: I got this wrong in the orig post of course put FAKEROOT in front slackbuild call , thanks bassmadrigal for the reminder!
thats the easy part

bit more reading through the src
if some one wants to switch between root and no root and different users, you work in the same tmp directory, than you need also think about that,
so possible prefix the temp directories for each user ... /tmp/SBo_${USER} possible
and if you are root than it is /tmp/SBo as it was, so its backward compatible
or dealing with rights, sbo group.. ?

these are a bit tricky, I think per default these will not work for a user,
LOGFILE=${LOGFILE:-/var/log/sbopkg/sbopkg-build-log}
QUEUEDIR=${QUEUEDIR:-/var/lib/sbopkg/queues}
REPO_ROOT=${REPO_ROOT:-/var/lib/sbopkg}
SRCDIR=${SRCDIR:-/var/cache/sbopkg}

its not a problem to handle this, but what would be a good place and/or rights for these?
or a sbo group where you have to be member of..?

fix the stuff that it works for personal use seems to be easy because you know your locations..
for general use the questions need to be solved.
but when these are solved fixing should be not a big deal and I think I can do it/

also maybe I should rely look for new tools
slpks seems to build also queues,
and slackrepo seems to be very active, possible I should start using this tool

yes, its never boring with Slackware :-)