The first request is for Pat.

For a long time I have mounted /tmp in tmpfs through /etc/fstab. I long have thought this tweak should be configurable for all users.

A common problem posted in this forum is hard disk partitions filling and running out of space. Almost always the culprit is building packages and not cleaning /tmp.

The request is to provide a configurable way to allow users to mount /tmp in tmpfs. I am thinking add /etc/default/tmpfs or something similar. Then modify rc.S to source that file and if configured, mount /tmp similar to the way /var/run is mounted in tmpfs.

Another option might be something like rc.tmpmount, possibly similar to rc.cpufreq.

I am asking for a configurable option and am not asking to change defaults.

Perhaps a sweet twist would be to add a setup.tmpfs script that would be available in pkgtool and the installer.

I will help with any testing if needed.

A second but similar request is for SBo maintainers. I edit all SBo build scripts to delete the compiling cruft. I add the following at the end of build scripts:

This snippet too would be optional and configurable.

Thanks.

Edit: Please ignore the second request.

For the second request I must strongly disagree. I often look at the source directory after the package is built when working on the SlackBuild script. Any cleanup should be at the user's discretion, my suggestion would be to create a cronjob that removes files in /tmp/SBo that are older than a certain date. This way you do not have to edit any SlackBuild files and can configure the behavior exactly to your liking.

2 members found this post helpful.

Maybe something like this in fstab:

And rc.tmpfs to optionally mount this on boot, if made executable.
It could be a problem with noexec, because some want to execute things in there and some don't.
So I was thinking both rc.tmpfs and rc.tmpfs_noexec - but I guess that's too much complexity for no good reason.

In my original post I wrote "This snippet too would be optional and configurable."

For some years I have used fstab: tmpfs /tmp tmpfs defaults,noatime 0 0

Certainly already doable by most Slackers. I am proposing a more "obvious" configurable method.

Using noauto would seem to provide an on-the-fly toggle, but I think many or most people would want a permanent configuration. Either in tmpfs or not.

I am now thinking rc.S could source rc.tmpmount. rc.tmpmount would source /etc/default/tmpfs. If /etc/default/tmpfs does not exist or is not set to true then /tmp would mount to disk rather than tmpfs. /etc/default/tmpfs could contain something like MOUNT_TMP_TMPFS=.

Icing on the cake would be a setup.tmpfs script.

I do not think mounting /tmp during normal usage (= not at boot time, but later) is safe. I would rather say that is dangerous. Therefore /etc/fstab is ok. I do not really understand what [else] do you want to configure.

I would rather try (although I'm not really familiar with slackware), to set TMP to something unique before build and delete that after build. Either inside /tmp or outside.

I think you should really want to NOT do this in Slackware. And in particular your SBo-related proposal is something that should be rejected forcefully.
This smells too much of the big distros. You want to take control away from the user.

Instead, you might want to document your improvement proposals in the Slack Docs wiki, so that people can incorporate these themselves if they want. IMO that's the proper way.

6 members found this post helpful.

sbotools covers this. Just configure /etc/sbotools/sbotools.conf to have it done automatically (specifically DISTCLEAN, NOCLEAN, and PKG_DIR).

I don't think implementation directly in the SlackBuild is a good idea, mainly because there would be an expectation for users that all scripts support this (which means work for SBo maintainers for a problem that is already solved, but also inevitable silent failures for the user). Say it was configurable with some shell variable ($CLEAN or whatever), the user wouldn't immediately know if the SlackBuild supports it or not (you'd have to check the script, check /tmp afterwards etc).

On the other hand, it's a useful functionality to have in an SBo management program. If the program you like to use doesn't support it, I think patches/update requests should go there, rather than the entire base of SlackBuild maintainers.

I'm not at my computer, but I am 90% sure that sbopkg has this feature already implemented as well. Just read the sbopkg.conf.

From the man page, it looks like sbopkg currently supports auto-cleaning the unpacked source and package tree (via CLEANUP), but perhaps not the downloaded source or the built package itself.

you can remove the old sources using sbopkg -o

Okay, forget about the second request to modify SBo slackbuilds. While I don't use sbopkg, I have been modifyng the SBo slackbuilds for many years to clean /tmp, even long before I started mounting /tmp to tmpfs. 'Nuff said about that topic.

I still think a configurable option to mount /tmp to tmpfs would be a nice addition.

I also have /tmp mounted on tmpfs, but isn't /etc/fstab already user configurable? It might not be a bad idea for the installer to ask if the user wants to enable it (if enough RAM is found to make it workable), and if not then the relevant line fstab line would remain commented out. Maybe I'm missing the point, but what's the reason for the other approaches you suggested?

Another user-side way of keeping /tmp maintained is, as i sometimes need more space on /tmp than i have ram, and here and there had X-login issues because of a cluttered /tmp:

auto clean after build is useful, especially if you have /tmp in ram. (think about an update that contains the bigger packages, like Qt)
today tools (some of them) already implement this, so this is an indicator for the usefulness of this function and a wider use-range.
a feature request for this option is therefore legitimate, especially if, as explicit stated, the current default behaviors should not change.
building a bridge to `the smell of big distros`, what ever this means, is a bit extreme, isn't it?
and why configurable options take control away from the user need to be explained, because to me it seems the other way it is.

Hello,


I second that. Furthermore, it is easy to implement something totally optional which could easily be added (automatically) at the end (ie. after /sbin/makepkg ...) of each existing SlackBuilds :

With this code, user can request cleaning of TMP & PKG directories on the command line :

The variable SBO_AUTOCLEAN can also be set to yes in ~/.profile. In this case user can prevent cleaning of TMP & PKG directories by passing SBO_AUTOCLEAN=no on the command line of any SlackBuild when needed.

--
SeB