SFS_Installer needs updating work by a programmer, please!

[scsijon]

The origonal SFS_Installer-0.1.pet was a Trio project.

The major problem is that once a sfs has been installed, there is currently no way of removing its components except by a long and laborous path if file by file removal, once you have a filelist, another long and laborous dissassembly of sfs task via the sfs2pet package.

I was wondering if one of our programmers would consider taking it on as a project to have it install like a pet with a filelist in /root/.packages and have a uninstall routine for the PPM by combining components of these two packages.

It's still used by those of us that full install, so if someone has the time, I believe it would be very much appreciated by quite a number of us.


thanks

scsijon
ps, couldn't find a SFS_Installer thread, just a single referance by 8bit to it's origin, and thanks to him for that much.

[8-bit]

You can find trio's original post with versions here.

With the introduction of SFS load on the fly utilities though, why would you want to revisit trios utility?

Also, what changes or improvements are you wanting?

[scsijon]

thanks 8bit, I spent over an hour with search and could not find a thread for Trio's package, very frustrating.

The problem is that it installs the selected sfs, but doesn't create either an entry for ppm to uninstall with or a package list to manually uninstall with. Yet it did according to trio's thread back in the 43x days, I wonder what has changed with wary/racy?

As far as sfs load on the fly, last time I looked at it, it was good for frugal installs, but had problems with full installs. I believe it also takes over valuable sfs mount points, which doesn't happen when you want a semi-permanently installed package that has been provided in sfs format. However I shall find and re-read the thread too see if it will do what is wanted.

thanks again
scsijon

[technosaurus]

My sfs linker in jwm_tools does this already. I didn't make a GUI frontend for it though since frankly there are already too many implementations and I am never satisfied with my own GUIs ... My other projects would suffer from neglect while I nitpick unimportant details in the UI.

So why then, did I bother to write it? None of the others supported vanilla kernels and most of them required extras or were slow. I wanted a fully portable version that could be used within an initramfs or a full install (similar to what tiny core does, but without having to deal with their antics)

Anyhow this is how I am doing all of my projects these days. Build and debug the backend (with possibility of a GUI in mind) , then let let the community decide if it needs or is worthy of a frontend.

BTW my code could be simplified with a "find" command, but I was trying to use only absolutely necessary shell stuff so it could go in the initramfs. Upon further examination most distros seem to include find(... must not be as stubborn as I am)

[sunburnt]

Side note:
SFSconvert didn`t work as the kernel doesn`t supported the old Squash format.

Another odd thing about it is, it seems to use HD space as a copy buffer.
Why not mount the old SFS file and use it directly to make the new one?
You only need HD space if you want to modify the contense, not just updating.

[jpeps]

The origonal SFS_Installer-0.1.pet was a Trio project.

The major problem is that once a sfs has been installed, there is currently no way of removing its components except by a long and laborous path if file by file removal, once you have a filelist, another long and laborous dissassembly of sfs task via the sfs2pet package.

The squashfs installs the files in it's own loop, so it's a lot different then a pet install. You don't want to delete individual files, like with a pet. Re using "mount points", i.e loops, I like to combine them when possible. There are several programs for doing this. I posted "rox-merge" somewhere in the SFS on the fly thread.

[shinobar]

I was wondering if one of our programmers would consider taking it on as a project to have it install like a pet with a filelist in /root/.packages and have a uninstall routine for the PPM by combining components of these two packages.

trio did it at SFS_Installer-1.0-430. It is also implemented in the Quickpet by micko and my SFS_load for full install support.

Feed back on SFS_load is welcome at the topic:
http://www.murga-linux.com/puppy/viewtopic.php?t=64354

[jpeps]

Here's a script to find the sfs loop, and read the installed files. Uses "tree"

Usage: sfscheck [searchword] --- finds loop number
sfscheck -s [loop number] --- prints tree of files

Code: Select all

#!/bin/sh

## find sfs files & check files .  Prints to /tmp/sfslist 

if [ "$1" == "-h" -o "$1" == "" ]; then
echo "Usage:  sfscheck [searchword]    find matching loop"
echo  "Usage:   sfscheck -s [number]     tree loop"
exit
fi

if [ "$1" == "-s" ]; then
 var="/initrd/pup_ro${2}"
 echo "$(tree  ${var}>/tmp/sfslist)"
 cat /tmp/sfslist | less
exit
fi


## determine the number of loops

n=0
for x in `mount | grep loop | grep -Eo [1-9]`
do
[ "$x" -gt "$n" ] && n="$x"

done

echo "${n} loops"

for i in $(seq 1 "$n");do
find  "/initrd/pup_ro${i}" -name "$1"
done

[sunburnt]

To help jpeps script...

Code: Select all

##############	from image file get mount point: $1 = (/path/image-file)
file2mnt() {
  [ -z "$1" ]&& echo '# Error: No input.!' && return 1
  loMNT=`mount |grep "/dev/loop"`
  [ -z "$loMNT" ]&& echo '# Error: No loop mounts.!' && return 3
  echo "$loMNT" |while read LINE
  do
   loDEV=`echo $LINE |cut -f 1 -d ' '`
   loFILE=`losetup-FULL $loDEV |sed 's/^.*(//;s/).*$//'`
   [ "$loFILE" = "$1" ]&& echo $LINE |cut -f 3 -d ' ' && break
  done
}

Usage: file2mnt ( /path/imageFile )

Example: file2mnt /mnt/dev_save/puppy528/lupusave.3fs
Returns: /initrd/pup_rw

# So jpep`s code can use the file as input.

# I`m sure technosaurus could turn it into a single Awk command.
..... I wrote this many years ago, so not the most efficient code.

### I have code to get any return from any input:

Image file -> loop device.
Image file -> mount point.
Mount point -> image file.
Mount point -> loop device.
Loop device -> image file.
Loop device -> mount point.

# All this code and more should be in a Puppy API.

If any interest, just ask... T.

[jpeps]

Okay...incorporating losetup

Usage: sfscheck [searchword] --- Find matching loop
sfscheck -c --- Show mounted loops
sfscheck [searchword] -f --- Print tree of files

Code: Select all

#!/bin/sh 

## find sfs files & check files .  Prints to /tmp/sfslist 

if [ "$1" == "-h" -o "$1" == "" ]; then
echo "Usage:  sfscheck [searchword]    find matching loop"
echo  "                [searchword] -f  print files" 
echo  "                -c               mounted sfs files"
exit
fi

 
if [ "$1" == "-s" ]; then
 var="/initrd/pup_ro${2}"
 echo "$(tree  ${var}>/tmp/sfslist)"
 cat /tmp/sfslist | less
exit
fi

## determine the number of loops

n=0
for x in `mount | grep loop | grep -Eo [1-9]`
do
[ "$x" -gt "$n" ] && n="$x"

done

echo -e "${n} loops\n"

## print mounted SFS files

  for i in $(seq 1 $n); do
  var="$(losetup /dev/loop${i} 2>/dev/null )"
    [ "$var" -a "$1" == "-c" ] && echo  "${var}" 

## search for mounted SFS file
  [ "$1" == "-c" ] || ser=$(echo "$var" | grep "$1")
   [ "$ser" ] && echo "$ser"

## Print files for searched SFS file
    if [ "$ser" -a "$2" == "-f" ]; then
      var="/initrd/pup_ro${i}"
      
      [ "$var" ] && echo "$(tree  ${var}>/tmp/sfslist)"
       cat /tmp/sfslist | less
    fi
done

[jpeps]

Weird...tried using this script after updating to Slacko-5.3.1, and the commands wouldn't work.

update:

Code: Select all

#!/bin/sh 

## find sfs files & check files .  Prints to /tmp/sfslist 

if [ "$1" == "-h" -o "$1" == "" ]; then
echo "Usage:  sfscheck [searchword]    find matching loop"
echo  "                [searchword] -f  print files" 
echo  "                -c               mounted sfs files"
echo  "                -s   [loop]     shows tree for loop"              

exit
fi

if [ "$1" == "-s" ]; then
 var="/initrd/pup_ro${2}"
  tree ${var} | less
exit
fi

## determine the number of loops

n=0

var=`mount | grep loop | cut -d/ -f3 | grep -Eo [1-9]+`

for i in $var; do
[ "$i" -gt "$n" ] && n="$i"
done

echo -e  "${n} loops\n"

## print mounted SFS files

  for i in $(seq 1 $n); do
  var="$(losetup /dev/loop${i} 2>/dev/null )"
    [ "$var" -a "$1" == "-c" ] && echo  "${var}" 

## search for mounted SFS file
  [ "$1" == "-c" ] || ser=$(echo "$var" | grep "$1")
   [ "$ser" ] && echo "$ser"

## Print files for searched SFS file
    if [ "$ser" -a "$2" == "-f" ]; then
      var="/initrd/pup_ro${i}"

      [ -d "$var" ] && tree  ${var} | less

    fi
done
   exit  

[sunburnt]

That`s Puppy... Now it works, now it doesn`t work...
Write an app. or even a utility and in a few versions it won`t work anymore.
If they`re GUI apps. ( gtkDialog ) then the usual cause is a new version of it.

Same with standard build system stuff, it`s in one version but not the next.
Consistency`s not a strong point and it makes development very difficult.

That`s what`s so great about SFS files, they`re separate from the system.
But they continually need to be updated also, probably easier to do though.