Fix the rc.update mess

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fix the rc.update mess

01micko
Administrator
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.

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.

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.

Thoughts?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fix the rc.update mess

JakeSFR
I won't be missing this feature.
Aarf too, I guess. ;)

Greetings!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fix the rc.update mess

jamesbond3142
In reply to this post by 01micko
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.

Remove it.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fix the rc.update mess

q5sys
and here I thought I was the only one who was annoyed by this.
I will throw a party when this is gone... and yes, you all are invited. lol


>> 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.
>
>Remove it.

--
Sent from Kaiten Mail. Please excuse my brevity.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fix the rc.update mess

Karl Godt
Administrator
In reply to this post by 01micko
rc.update runs also if shinobars
 sfs_load
alters any files, ie
/etc/rc.d/BOOTCONFIG .

When changing of
LASTUNIONRECORD to
PREVUNIONRECORD
fails in
/init
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
#sync

and  
b) a lot of still UNKNOWN mess ..

442 - 542 inclusive
are
 #fix the desktop...
 #note, init does 'touch' on PuppyPin and globicons to prevent overwrite at version upgrade.

Don't know how this all works in PRACTICE ..
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fix the rc.update mess

01micko
Administrator
This post was updated on .
In reply to this post by 01micko
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fix the rc.update mess

01micko
Administrator
Initial tests are a resounding success :-)

Boot, save, change icons, reboot no mess

Time for a beer, while the thing uploads at a crawl.. if I do it at full speed it sucks the guts out of the internet for wifey and son.  = not
Loading...