On Thu, 19 Jun 2014 07:22:44 -0700 (PDT)
"01micko [via woof-CE]" <[hidden email]> wrote:
> rc.update has had a bug for ever. There are some old bugs in puppy but I
> reckon, from a visual perspective, this is the oldest and most annoying.
I remember this "feature".
It *is* very annoying. I spent hours aligning my icons properly only to be undone when I load/unload an SFS.
> Every time you load an sfs, then reboot the icons are screwed.
> I think BK's rationale for the routine was, that if the sfs contained icons
> to be displayed on the desktop (take a look at one of his old openoffice
> sfs) that this was the way to do it.
If this is the reason, then the better way is to have something like "pinstall/puninstall.sh" scripts that get called each time an SFS is loaded or unloaded. Let the SFS sort out the icons etc. If you don't like the idea, then the SFS loader must detect and take care of the icons (or anything else that we want it to take care of).
If you are for the pinstall/puninstall script for SFS, I have a proposal (script locations, etc) since I already have a working implementation for Fatdog (since 630). Let's keep the details the same so we can retain a bit of compatibility for the future.
> As far as I'm concerned, we should delete lines 442 - 542 inclusive. We can
> deal with the consequences later, wont be much if any IMHO.
rc.update runs also if shinobars
alters any files, ie
When changing of
there is " as usual "
a) no error check for
#update /etc/rc.d/BOOTCONFIG with latest layered-fs layers configuration... #100222 fix...
xBOOTCONFIG="`grep -v '^PREVUNIONRECORD' $OLDFILESMNTPT/etc/rc.d/BOOTCONFIG | sed -e 's/^LASTUNIONRECORD/PREVUNIONRECORD/'`"
echo "$xBOOTCONFIG" > /pup_rw/etc/rc.d/BOOTCONFIG
b) a lot of still UNKNOWN mess ..
442 - 542 inclusive
#fix the desktop...
#note, init does 'touch' on PuppyPin and globicons to prevent overwrite at version upgrade.
The only thing useful I can see in there is retaining the user set background.. but no, it won't change if we don't touch the puppypin. If user changes desktop layout that is in the save file and already on the top layer too. Sure, if a user upgrades and the developer has decided to change the icon layout then that won't be translated to the user, but so what? User is happy with his/her icon layout.
The way wallpaper is set is broken by design anyway. "default.jpg" will work fine as a symlink, but I am not going to bother with that. It's only a few clicks to restore the favoured image. The only user who loses is the one who adored the original "default.jpg". FWIW, I reckon that user is virtually non existent! It's always the first change some one makes! One scenario that will break.. if the default wallpaper is PNG, "default.png". I can live with that.
Ok, I've decided. I'll comment that whole block. Any detrimental effects can then be easily found. If it's all good after a couple of months the commented block can be deleted in a round of clean-up. EDIT: pushed