well, being people human, I suppose both submitters and who has to check might miss something: that's what bug reports are for.
if you report stuff in the proper places you might avoid more propagation.

I think missing something had happened to anybody: when you maintain a repository with nearly 5000 build scripts statistics say that might just happen more often...

fixing it for personal use is not a problem, there are several ways to do
but the way you choose might not be that one an other person likes,

sometime unfortunately and sometimes fortunately we have no 'standard' way of doing some things at Slackware,
or the 'standard' way is not the best one, not the best one for everybody or even broken for some.
this is good sometimes, and sometimes not that good because it leads to an enormous amount of redundant work.
does any distribution have more package build tools and redundant build scripts like Slackware?

however, thinking about packages,
does anyone know about openbuildservie,
and the internals,
can there be a backend for Slackware be appended, written, does anyone know?

yes and that's why they should not run build scripts as root because those kind of errors can not happen that way. it is a quality improvement. it has just advantages, its that simple.
I should put this in my signature

IMHO, that's not harmful if you build in virtual machines/containers/chroots and you use snapshots/backups of the vms files.

as I see it, Slackware lets you to be free to do whatever as you prefer: it gives you good practices but it doesn't force anything down your throat.
that's why there's a proliferation of mods/tools, because it's easy to do so with such a base.

2 members found this post helpful.

does not help you to detect and avoid these kind of errors in the scripts I am talking about

ivandi,

Can you sum up all your worries about SBo, suggesting constructively what to improve and how. Then, post all this to the SBo mailing lists? As you stated, people at SBo are good people , so they will at least read carefully what you have to say.

Cheers

2 members found this post helpful.

LOL... yeah been there (HP-UX), many years ago, thanks goodness for backup tapes.

Amen. Very annoying. Sort of like "Are you sure you want to log out?"; yes I am sure, I clicked Log Out didn't I!

I did not say that "Slackware sort of approved" SlackBuilds.org.
Before creating the site, we discussed with Pat what the potential consequences could be if the site would become popular. We did not want to rub off Pat or step on his toes. What we wanted to avoid is to create a way of building packages that was not the same as how Slackware is doing things. In case of rising popularity of SlackBuilds.org, there was a real chance that people would start demanding of Pat that he change the way packages are built in Slackware.
Therefore we decided to stick to the way Slackware packages are created. The Slackware way of working is our template, so to say.

We did not ask for or even want to have Pat's approval. We just wanted to stay on friendly terms. At the time of creating the site, Robby was not part of the Slackware coreteam by the way. I was, but being on the coreteam does not mean that I am affiliated with Slackware. What happens at SlackBuilds.org is completely independent of Slackware, Inc. Affiliation means a possibility of influence or control, and this is not the case. My role (and Robby's) in the coreteam is one without financial ties, we do this purely voluntarily and in our own free time.

1 members found this post helpful.

The SBo mailing list is highly responsive.

Oh my, back to FAQ 11. OK, I give up.

Cheers

He implied that you'd examine the resulting VM after running the script, to see what (if anything) got trashed.

Brian's Law: If a thread is started in the Slackware forum, it is certain to drift off-topic.

4 members found this post helpful.

Yep, you can use snapshots to roll back to before install and compare but it can be tricky to know where to look. One way is to use find to generate a log of all files (in common install directories /bin, /etc, /lib, /opt, /sbin, /usr, etc.) with time stamps (or md5sums if you are really paranoid). Then do the packaging, repeat the find command and diff the results.

I think a project that is going in the right way to help packagers has already been hinted by 55020 and it's the one pprkut started (and to which he contributed)

https://github.com/pprkut/lintpkg

to check if stuff goes in wrong places, aide can be useful (but maybe can be a little overkill)

http://slackbuilds.org/repository/14.1/system/aide/

2 members found this post helpful.