(old)Puppy Linux Discussion Forum

noryb009 wrote:We at least took a sample* of the signed up "Suggestions" board readers. 16/25 people voted for a new format, which is 64% - almost two thirds of the users. You are welcome to put up a poll in a more viewed area, but until we get more data, we should to use the data we have - which is to create a new package format.

* I can't link directly on the forum as the link contains brackets. Real path is: http://en.wikipedia.org/wiki/Sample_(statistics)

amigo wrote:Thanks for helping out there with the meaty answers. So, when you boot a 'frugal' installation, the intrid (a fat one?) is used, setting up the main sfs as the root partiton, then the save file is unioned above that? Is that about the flow of things?

jemimah wrote: This is old but mostly still accurate:
http://puppylinux.com/development/howpuppyworks.html

2byte wrote: Jemimah, I agree Barry should not rewrite woof to suit us, but I don’t think he would have to. I am not a woof expert by any means but there has to be a place during the build when the pets and packages are being added where a branch could be made to a separate routine that could assemble the package/file info for use in the database. If we presented a plugin bash routine that would do this surely he could call it from woof at the appropriate spot.

The plugin could produce a record of the package/pet with a complete list of files. The file paths, permissions, owner:group, size, time added, and md5 could be produced. Probably the package type and, if it’s a distro package, where it came from could also be recorded. If the package/pet has a dependency list, build script or info, or pinstall or doinst script then that could be recorded too. At the very least we could produce the package name and related file list.

jemimah wrote:

I'm just not seeing what you think this DB is going to do for you. What functional enhancement is this going to provide?

You can pull the package name, dependencies, origin, and related file list out of puppy's existing DB.

noryb009 wrote:jpeps: People not voting doesn't mean that they don't care - it means .....

2byte wrote:Package management.

I think we all agree that full super duper pm is not possible with puppy.

but I guess it didn't catch on

Disciple wrote: No, I for one don't agree - I think that is nonsense.
And particularly for a woof based puppy - what are the barriers to using the native package manager of the parent distro?

jemimah wrote: Big_bass apparently got it working pretty well with TXZpup, but I guess it didn't catch on and he went to go work on Porteus instead.

jemimah wrote:

amigo wrote: The "fat initrd" was pretty much a passing thing. 99% of the time a small initrd is used.

jemimah wrote: I'm just not seeing what you think this DB is going to do for you. What functional enhancement is this going to provide?

You can pull the package name, dependencies, origin, and related file list out of puppy's existing DB.

Moose On The Loose wrote:
This brings to mind a suggestion I made before. Perhaps if things are being worked on, it should be considered:

Make the layers like this:

*************************
Current work
*************************
root & my-documents & perhaps my-applications
*************************
All hardware related settings installed pets etc
*************************
Any loaded extending SFS files
*************************
The main SFS file
************************

This way, when someone changes machines or changes versions of puppy the documents he is working on etc can appear in the new machine or version without trouble. It would mean having two save files but other than that it would not be a major change to the way things are done except keeping track of the files from the pets. We know what directories have the
settings.

The order I show has the pets replacing the SFS files when there is a conflict. I think that this is the right order because the pets are usually done only after the first re-boot if you want to use some SFS.

jemimah wrote:
For woof-installed packages, you can find a copy of the pet.specs in /root/woof-installed-packages. The pet.specs contains the package name, dependencies, and origin. The list of files is in /root/packags/builtin_files/<packagename>. Barry uses a compressed format that is different than the filelist for user installed packages, but all the information is there. The only thing that is discarded is the pinstall and puninstall scripts - most packages don't have these anyway.

jemimah wrote:Searching the file is probably not as hard as you think it is.

Code: Select all

cat woof-installed-packages | egrep  ".*\|.*zip.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|"

#!/bin/sh

OLD_IFS="${IFS}"
IFS="|"

cd /root/.packages

var=`cat woof-installed-packages | grep ${1} `

for i in $var; do
 var=`echo  "$i" | grep "^${1}"`
  [ "$var" ] || echo "$i" | grep "^lib${1}"
done

IFS="${OLD_IFS}"

cat woof-installed-packages |egrep  ".*\|bc\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|"

real 0m0.008s
user 0m0.006s
sys 0m0.002s

cat /root/.packages/builtin_files/<packagename>  | 
while read LINE ; do 
  if [[ $LINE =~ '/.*' ]] ; then 
    DIR=$LINE
    continue 
  else 
    echo ${DIR}/$LINE
  fi
done