Fair Warning! Don't use /tmp diretory in .pet packages

[taersh]

Fair Warning!

No, this is not about the Van Halen album. It's dedicated to all Puppy developers who creates .pet packages using pinstall.sh scripts.

If a developer needs to use such pinstall.sh script e.g.to copy files from /tmp to another location -e.g. to avoid overwriting files already existing- don't do that. It will break the Puppy.

I don't know exactly when this had changed, though I experienced problems in FossPup64 9.5 after installing a .pet package having such a pinstall.sh script. It's because in FossaPup /tmp is a symbolic link which gets overwritten by the installed package.Therefore all the pup_event functions were removed. So, clicking a drive icon won't open drives/partitions anymore. The functions will return after restarting X, though anything else in /tmp still is lost - which perhaps might cause even more trouble when using save files or save folders.

Since the forum has no general developer section -at least I couldn't find one-, I decided to post this here.

[Wiz57]

Since the forum has no general developer section -at least I couldn't find one-, I decided to post this here

Hmmm, maybe that would be a good suggestion, add a new sub forum. In the "Programming" forum maybe?
Good catch, by the way...scripts need to implement measures to determine what data they add, and only
work with that, not what is linked to, already there, etc.
Brings back memories of late 1990s when I worked with Arachne for DOS...in some of the initial installer
batch files, if the "temp" variable was not set via config.sys or autoexec.bat, some installer script would
default to C:\DOS...then when the script finished, it would delete temp files, and subsequently EVERYTHING
in C:\DOS, leaving the computer inoperable, needing DOS reinstalled!
Wiz

[MochiMoppel]

I don't know exactly when this had changed, though I experienced problems in FossPup64 9.5 after installing a .pet package having such a pinstall.sh script.

Which .pet package?

[ozsouth]

I wrote about overwriting /tmp in ScPup64 early this year. Is a symlink in that pup too.

[taersh]

Which .pet package?

An older program I developed when I was working on L.A.S.S.I.E. - not published as far as I can recall.

[greengeek]

Do you have any suggestions as an alternative to pinstall scripts?

Sometimes i want to do things before pet files are installed, but sometimes i want to do stuff after the pet files are installed.

I see Debian has two kinds of scripts for that purpose.

Some pets i have used for years on Slacko 5.6 fail during my recent experiments with Tahr32 etc (because of different timing handling pinstall scripts) so I am keen to know how to handle pet installation better.

[taersh]

"Don't use pinstall cripts to make .pet packages"

Sorry, but I didn't wrote this. The title I wrote was "Fair Warning" only.
My warning was meant to the /tmp directory inside of a .pet package.
E.g in FossaPup64 /tmp is a symbolic link which gets overwritten by the /tmp directory inside the .pet package.

The title has changed later, but it wasn't me.
I'm still using pinstall.sh, though I don't place it into a /tmp directory of the package.
Instead I'm creating another directory to place files to be installed by the pinstall.sh script.

Edit: I changed the title now.

[Jafadmin]

So, am I right in understanding that you mean, "Do NOT include a /tmp directory in your .pet package"?

If so, I'm struggling to understand why one WOULD do it to begin with .. '/tmp' is one of the reserved OS directories like /dev, /run, and /sys

[taersh]

1. Directory /tmp is a directory for temporary files. This means it's for files temporarily stored.
There could be many purposes to store files temporarily into /tmp or into a sub-directory of /tmp.

It's completely stupid to look at it as a reserved OS directory, and it's even more stupid to define it being a reserved OS directory.

A reserved OS directory should include content like it is in /dev, /proc, and /sys.
These directories obviously are not created/designed to store temporary files or even user files or even programs etc.

2. In older Puppies /tmp was a real directory. Not being a symbolic link like in the newer Puppies.
Even inside the initrd.gz, /tmp is still a real directory. And also inside of the base .sfs it is still a real directory.

And by the way: /run should also NOT being a reserved OS directory.
And by another way: /run is a symbolic link to /tmp in Puppy.

So, in newer Puppies somewhere within the boot process it changes to being a symbolic link.

My purpose of putting a /tmp directory into a .pet package is/was: installing files via .pet package and copying those files by the use of a pinstall.sh script. Within the pinstall.sh script I can make checks if the file is already existing, or if it is newer than the file in /tmp of the .pet package. So, that way I can avoid overwrite an existing/newer file. E.g. providing updates of a .pet package without to spare files out like .cfg files that may have changed by the user who already installed a first version.

I wrote:

If a developer needs to use such pinstall.sh script e.g.to copy files from /tmp to another location -e.g. to avoid overwriting files already existing- don't do that. It will break the Puppy.

[Jafadmin]

It's completely stupid to look at it as a reserved OS directory, and it's even more stupid to define it being a reserved OS directory.

Read: https://www.fosslinux.com/41739/linux-t ... o-know.htm

[rcrsn51]

Even in old Puppies, using /tmp in a PET package was a problem. The /tmp folder needs full 1777 permissions so unprivileged processes (like in CUPS) can use it. Copying /tmp content out of a PET would often change it to 755.

[Jafadmin]

Even in old Puppies, using /tmp in a PET package was a problem. The /tmp folder needs full 1777 permissions so unprivileged processes (like in CUPS) can use it. Copying /tmp content out of a PET would often change it to 755.

I had learned years back that the solution was to use /var/tmp

[rcrsn51]

I had learned years back that the solution was to use /var/tmp

It's exactly the same problem with /var/tmp. If a CUPS filter uses /var/tmp (some do) then it needs 1777 privileges too. So a PET that contains content in /var/tmp will cause trouble.

[Jafadmin]

I had learned years back that the solution was to use /var/tmp

It's exactly the same problem with /var/tmp. If a CUPS filter uses /var/tmp (some do) then it needs 1777 privileges too. So a PET that contains content in /var/tmp will cause trouble.

But /var/tmp isn't a symlink, and both tmps are supposed to be 1777 by default.

[taersh]

Hi.

Thanks for all the useful knowledge being new to me.
Meanwhile I have edited most of my .pet packages.
Instead of /tmp or /var/tmp I'm using now my own hidden temporary directory in /root to do what I need by the pinstall.sh script.

Again thanks!

[Jafadmin]

Good plan!