How to conditionally place .desktop launchers from .pet?

[JASpup]

I do not think Tahr had a defaultfilemanager.desktop so I made one.

If I use the same .pet in Xenial with a pre-existing defaultfilemanager.desktop launcher, how do I not overwrite the one that already exists?

[williams2]

You could save a backup copy of your .desktop file somewhere, and copy it back if needed.

[JASpup]

There isn't a way to conditionally place files?

My default old trick is to make different copies of the .pet, i.e.,

32Thunar_1.6.10-Tahr.pet
32Thunar_1.6.10-Xenial.pet (no defaultfilemanager.desktop)

Inefficient but it works when the new dog can't learn all the old tricks.

[OscarTalks]

The fact that different Puppies will have different files already on-board is ONE of the reasons to have different .pet packages for each flavour of Puppy. Since you would not normally be installing a package on a frequent basis, your previous solution sounds like the best one.

BUT, as an academic exercise, since you are talking about a CONDITIONAL step, you might want to play around with having a post-install script (pinstall.sh) in the .pet with a simple
if > then > else
So the .pet installs the package's defaultfilemanager.desktop in a temporary location (maybe /tmp or even /root)
Then the pinstall.sh does:-
if the file /path/to/defaultfilemanager.desktop exists
then delete the defaultfilemanager.desktop from the temporary location (leave the original in place)
else move defaultfilemanager.desktop from temporary location to correct location
fi

[JASpup]

BUT, as an academic exercise, since you are talking about a CONDITIONAL step, you might want to play around with having a post-install script (pinstall.sh) in the .pet with a simple

Yes, I could put a launcher in the under-utilized /tmp directory.

The project prompting the question would be a .pet, but curious, do the (un)pinstall.sh scripts also work with .sfs?

I think I notice some .sfs browsers doing extra scriptwork upon loading.

[OscarTalks]

No, pinstall.sh and puninstall.sh scripts do not work in .sfs packages
But .sfs packages are not really "installed" anyway. They are loaded within the layered file system.
If they are loaded below the main puppy.sfs (which is the normal), then the file in the package would not overwrite the original, it would be beneath it (and concealed by it).
There was talk in Puppy development of having the option to load .sfs packages above the main puppy.sfs
Even if this happens, it is not a problem if the file in the package is equally as good as the original which it lays above.
Furthermore, either way, if the .sfs is later unloaded, the file returns cleanly to how it was before loading.

[JASpup]

If they are loaded below the main puppy.sfs (which is the normal), then the file in the package would not overwrite the original, it would be beneath it (and concealed by it).

If loaded .sfs are below puppy.sfs, that would explain, why, say, we can't load a newer Pale Moon over a builtin, and more the reason to never include a builtin browser we'd expect to update. It's always there and bound for conflict.

I'll have to pay more attention to the .sfs I load, but am probably getting ahead of myself project-wise.