are here some SBo developer ?

atelszewski · 09-01-2015, 09:43 AM

Hi,

First of all, I'm heavy user of sbopkg. Second of all, I don't like building in /tmp.
This being said, I have:

Code:

export TMP=${TMP:-/home/software/slackware/pkg/tmpdir}
export OUTPUT=${OUTPUT:-/home/software/slackware/pkg/sbo}

in /etc/sbopkg/sbopkg.conf.

@USUARIONUEVO
Are you using sbopkg? If so, then try setting CLEANUP in /etc/sbopkg/sbopkg.conf. From man page:

Quote:

CLEANUP
Boolean.
When set to YES, the unpacked source files and package tree in $TMP are deleted right after the build, though the downloaded source archive and completed package are left in $SRCDIR and $OUTPUT.
A side effect of setting CLEANUP to YES is that TMP is set to sbopkg's own temporary directory ($TMPDIR/sbopkg.RANDOM_STRING) and any other TMP setting is ignored.
The default assignment is:
CLEANUP=${CLEANUP:-NO}

Don't ask for SBo official SlackBuilds to be changed to cleanup after themselves as this will (hopefully) never happen.
I prefer that the script does not clean up after itself, but if you use some tool to manage the build, then the tool can perform cleanup actions if you wish so. Look, if you build the Linux kernel from source, then the build directory is not cleaned up automatically after the successful build. It's a matter of having the CHOICE. Imagine that if the SlackBuild would cleanup after itself, then if somebody wanted the files generated during the build, he would have to modify the SlackBuild not to remove the files. I think it's easier to predict where the build files are going to be placed (SlackBuilds have very well define structure) and cleanup after the build, than to modify the auto-cleanup SlackBuild not to cleanup.

If you're using homegrown SlackBuilds then the choice is up to you, but keep in mind that for the wider public there is well established standard that is going to be kept.

@Didier

Quote:

We shouldn't change 5471 SlackBuilds (that's for Slackware 14.1 at time of writing), just to satisfy one user's request (and make how many users unhappy?), whilst this user could easily write a small script to fit his needs or wishes, not changing anything in the SlackBuilds.

What's wrong with satisfying one user's request? If possible, we should satisfy it, if not, then we shouldn't.
In that case it's not possible, so we won't.

--
Best regards,
Andrzej Telszewski

Didier Spaier · 09-01-2015, 10:12 AM

Quote:

Originally Posted by atelszewski

@Didier

What's wrong with satisfying one user's request?

Nothing of course. But I didn't say it's wrong.

Quote:

If possible, we should satisfy it, if not, then we shouldn't.
In that case it's not possible, so we won't.

In this case it is (technically) possible, but I don't agree with "if we can we should". We have to anticipate the consequences of a proposed change in every case before making a decision[1] and in this one here is how I see them:

a lot of work
a risk of unsatisfying many users

All that for a change any user can live without. After all no one is prevented to set TMP as one sees fit. Otherwise we would see in the templates:

Code:

TMP=/tmp/SBo

instead of:

Code:

TMP=${TMP:-/tmp/SBo}

[1] Caveat: I mean that's what I would recommend if I were to participate in the decision, but I am not a member of SlackBuilds.org team.

atelszewski · 09-01-2015, 10:26 AM

Hi,

Quote:

In this case it is (technically) possible, but I don't agree with "if we can we should".

Hey, the whole sentence was

Quote:

If possible, we should satisfy it, if not, then we shouldn't.
In that case it's not possible, so we won't.

so I agree with you that we should not change a single line

--
Best regards,
Andrzej Telszewski