SFS-TCZ_Linker-2.2.pet

[Squishy]

Hi, could someone give me a hand setting this up in a full install of NOP 431r1? Installed the pet but there's no sign of it on right click, so I assume its not compatible with XFCE?

[jrb]

Installed the pet but there's no sign of it on right click, so I assume its not compatible with XFCE?

I don't know anything about XFCE but perhaps this link will help:
http://thunar.xfce.org/documentation/C/ ... lders.html
The Application that you want to Open With is /usr/local/bin/sfs_linker.

Good Luck, J

[jrb]

I have uploaded a new version of SFS_Linker. It will load both SFS and TCZ (tinycore linux) packages. Also contains minor improvements in file handling.

I have included two versions. One with replacement /usr/local/bin/defaultprograms so your loaded programs will become the defaults and one without.

Both contain a link to the TinyCore sfs4 repository on the internet menu.

http://puppylinux.ca/members/choicepup/ ... bk-1.2.pet

http://puppylinux.ca/members/choicepup/ ... ef-1.2.pet

[Dingo]

Dear jrb, I remember you said an sfs, in order to be used by sfslinker needs to have a /usr/ dir, even it is blank, this is ever required also with your new version? anyway, having build some sfs packages recently, I remember these sfs have a /usr/ dir

[jrb]

Hi Dingo,
You remember correctly. and that is still the case.

I needed a way for sfs_linker to check if the .sfs had mounted correctly in /mnt/XXX.sfs before continuing with the symlinking so I had it check for the existence of /mnt/XXX.sfs/usr. Likewise when uninstalling, sfs_unlinker makes sure the file has unmounted by checking to see if /mnt/XXX.sfs/usr has disappeared..

So even if your .sfs doesn't need /usr, include an empty one.

Hope that helps, J

[jrb]

A summary of my findings so far for TCZ files, collected by veiwing the .dep files and error messages on command line:

• firefox.tcz and thunderbird3.tcz require dbus.tcz and dbus-glib.tcz (menu items in Network menu)
  opera10 requires qt-4.5-base.tcz (on the Systems menu)
  blobwars.tcz requires libmad.tcz and SDL.tcz (on the fun menu)
  supertux - same as blobwars
  clamav.tcz requires libiconv.tcz (command line "freshclam" to update and "clamscan -r /your_dir" to run)
  gimp2.tcz requires babl.tcz and gegl.tcz (on Graphics menu)
  Mplayer-nodeps.tcz needs Glibc2.7 so doesn't work
  xfe.tcz requires fox.tcz (command line)

[Dingo]

Dear jrb (again) can your sfslinker used on puppy 3.01 series or it needs to be hacked to result working? It would be very useful having a devx mounting on fly for 3.xx series. I have used sfslinker to live-mount devx in 4.3.xx puppy series in order to compile some apps and it has worked very fine for me

[jrb]

Hi Dingo,
I just tried the latest SFS-TCZ_Linker in Puppy301 and couldn't get any of my .sfs3's to mount. Not sure why. I do know that the unlinker depends on software in the woof petget manager which is quite different than the previous non-woof Puppies. Early on I tried Linker with Puppy218 which uses woof but still my sfs3's wouldn't work. As I remember it was because they were compiled against a later glibc.

Glad to hear that about the devx.sfs. I haven't tried it with linker. I don't use it that often and when I do I'm usually doing something I find intimidating so I have been conservative and mounted it with BootManager.

If you have a link to sfs's that you know work with 301 post it here and I'll try one or two of those.

Bye for now, J

[elraven]

hi jrb , just dropping line to say the no def version of sfs linker works great in spup 451. This pet is so great ,keep up the good work.
elraven

[Dingo]

Hi Dingo,
I just tried the latest SFS-TCZ_Linker in Puppy301 and couldn't get any of my .sfs3's to mount. [...]If you have a link to sfs's that you know work with 301 post it here and I'll try one or two of those.

made a test

- launched Puppy linux 3.01 from live Cd
- installed sfslinker
- loaded devx-sfs for 3.01 with sfs linker

result: successful; I have then tried with some other sfs (v 3.0 version, because I have discovered on puppy 3.xx series squashfilesystem v. 3.0 only is read, 3.1 not, and since 4.2.xx puppy linux series still able to read squash filesystem v . 3.0, is better, for older puppies, make v. 3.0 sfs) and installation was successful (unlinking also)

we have, however, a couple of minor issues

- first: an error message showed at sfslinker install


- second: when sfslinker installs itself, it seems de-associate icons on pinboard items so links are broken

[jrb]

when sfslinker installs itself, it seems de-associate icons on pinboard items so links are broken

Sorry, I forgot to mention that happening in my last post.

I seem to have found an easy fix however. Just go to /root/.config/rox.sourceforge.net/ROX-Filer/ and delete the globicons file. When you run your mouse over the desktop icons they should come back.

Apparently Puppy301 doesn't expect to find a globicons file there. In Puppy4XX globicons is hard linked between /root/Choices/ROX-Filer/globicons and /root/.config/rox.sourceforge.net/ROX-Filer/globicons

[jrb]

BTW - what is that tcz folder for?

Now its my turn to be embarrassed. I forgot to put a readme file in that folder.

If you make a /mnt/home/tcz folder and keep your .tcz files there then symlinks will automatically be made to the /my_links/tcz folder at bootup, kind of like the /my_links/sfs_mnt_home folder. From there you can copy the links you want to /my_links/sfs_boot_links.

[WarMocK]

Okay, this tool is made of awesome, thanks for creating and sharing it.
However, I found an unpleasant flaw in the design: I had GIMP-2.4.5 installed with a dotpet on my test system and then linked an SFS with the same version of GIMP into it as well. When I unlinked it, GIMP didn't work anymore. Obviously, the symlinks overwrote the installed binaries and got wiped when I unlinked the SFS. Okay, I simply re-installed GIMP afterwards, so nothing of value was lost, but this is a SERIOUS problem nevertheless. Apparently, SFS_linker does not test if there's already a link or binary with the same name available in the system and simply overwrites it. I don't want to imagine what happens if the SFS file contains system critical .so files ...
In my opinion SFS_linker desperately needs to read the content of the SFS, make a list from it, and then check if the system already has some of the files it would create symlinks for. If yes, SFS_linker needs to skip these links and remove them from the uninstall list when unlinking the module again.
In order to prevent a dependency hell when an older SFS is unlinked that already brought some shared libs needed by a newer SFS, it might also be a good idea to let the unlinker re-link the other sfs files to fill the gap. I know it would take some time, but it's better than if you lose half of your system because some critical programs won't start after you made an update.

[jrb]

Hi WarMock,
Sorry to hear about your difficulty. You raise a good point but I'm not sure there is a good fix.

Obviously, the symlinks overwrote the installed binaries and got wiped when I unlinked the SFS.

Not quite. SFS_Linker will not create symlinks over the top of existing files but it keeps track of what symlinks and files it has created (or tried to create) and copied (or tried to copy) exactly as package manager does. It creates a list of the files in /root/.packages/XXX.files, sadly it does not distinguish between symlinks and files. When you uninstall the SFS it deletes these files and symlinks regardless of whether it created them or not.

For each file both SFS_Linker and package manager check with the original pup-xxx.sfs and if a file with the same name exists there it will reinstate it. (Only from liveCD or frugal installs, full installs suffer the full consequences) However no such mechanism exists for previously installed .pets or .sfs's. Uninstalling and then reinstalling the original .pet is the only fix at present.

If you have added truly system critical files then you might want to think about remastering the pup-xxx.sfs so they will be safe. This is now easily done with Pizzasgood's edit_sfs-2.1.pet.

This is one of the reasons I quit using full installs, too easy to delete critical files.

Hope this helps. I will continue to think about the problem, perhaps there is something that can be done.

Cheers, J

[technosaurus]

One way would be to relink all other loaded sfs files after an unlink - if you wanted to get all fancy you could check for duplicate filenames and only do those, but also a lot of trouble so it may be better to just have a "relink all" button or default setting or something of the like.

[WarMocK]

@technosaurus: my thoughts exactly.

@jrb: Thanks for the clarification. At least I know what happened now. And don't worry, it wasn't more than a little inconvenience, relinking the sfs already did the job.
Another thing I noticed when I started working on the Beta 4 version of K-9 Linux: After installing SFS-Linker, I had big troubles with the Terminal: I couldn't close it normally. Instead, XFCE warned me that the program is busy and offered me to terminate the whole process. I don't know if this is an issue with puppy 4.32 (I had no such problems with NOP 4.31) of if I accidently left out a few important scripts or patches when I compiled the barebones system with Woof, but I thought I should let you know.

[jrb]

One way would be to relink all other loaded sfs files after an unlink

That is easily done but the real problem is SFS_Linker deleting files installed with .pets. Perhaps it could backup files that already exist and then reinstate them from backups.

[WarMocK]

Or you could try to keep track of what symlinks were actually created and note them down in a separate text file. Upon unlinking, you could use that list instead (after checking if the symlink is still valid OR if it has been overwritten with a real file).

[jrb]

I don't know if this is an issue with puppy 4.32

Can"t find the post but Barry mentioned that 432 had the "wrong" gtk+ version. I had problems with some of the SFS's and rewoofed it with gtk+-2.14.7-1-p4 as used in puppy431 and have had no problems since.

[WarMocK]

Hmm, not good. Fortunately I still have a core system created from Puppy 4.31 here.

Oh, and for the XFCE users here:
I've written a little code snipplet that allows you to toggle the sfs_linker to load an unloaded sfs file and vice versa (it works with JWM/ROX as well, of course ):

Code: Select all

#!/bin/sh

if [ `ls $HOME/my_links/sfs_loaded | grep $1` != "" ];then
   sfs_unlinker `ls $(pwd)/$1` 2> /dev/null &
else
   sfs_unlinker `ls $(pwd)/$1` 2> /dev/null &
fi

exit $@