Keep on finding bugs

Bugs keep getting unearthed, even in code that has been working OK for years.

Desktop icons
First though, a mention of icon sets. Yesterday I installed the Oranchelo and Sarai icon set PETs. After selecting them, I discovered that there were no icons in the JWM menu.
This is because the developer renamed SVG icons with .png extensions.
I have sent a PM to the developer, with advise how to fix this. He will have to fix and re-upload those PETs.

Package installing
/usr/local/petget is where all the scripts are for the PPM (Package Manager).
Yesterday, I installed a PET that has /lib and /lib64 folders in it, where /lib64 is a symlink to /lib
Yikes, in my SlaQ Quirky, which has /lib64 NOT a symlink, it got wiped out and a symlink /lib64 to /lib created.

This is obviously dangerous behaviour! Yet the code has been there for years. In my woofQ, until yesterday anyway, and yep, still in woof-CE:
https://github.com/puppylinux-woof-CE/woof-CE/blob/testing/woof-code/rootfs-skeleton/usr/local/petget/installpkg.sh

...look at line 343 onwards, that is where the naughty code is. I don't know what my thinking was at the time. Anyway, i have deleted the entire if - else -fi, from lines 344 to 367.

The woof-CE and woofQ 'petget' scripts have changed a lot since forking from Woof2, my woofQ scripts are going in their own direction. However, they both have that section of offending code.

---

Comments

Good, mavrothal has implemented the fix in woof-CE:

https://github.com/puppylinux-woof-CE/woof-CE/commit/d340723b9867c54e51d0e58c864a2f9c3ef4744f

I have been trying to think what my original reasoning was, to allow that behaviour. Perhaps, when installing a Service Pack, to allow major changes to the f.s. directories. But generally, it seems a very bad idea, allows a rogue PET to mess up the f.s.

Tags: linux