The State of Package Management

What features/apps/bugfixes needed in a future Puppy
Post Reply

Should Puppy's package format be changed?

Yes, without backwards compatibility.
11
28%
Yes, with backwards compatibility.
10
26%
No, but the PET format should be standardized/stricter.
8
21%
No, the PET format works fine.
10
26%
 
Total votes: 39

Message
Author
noryb009
Posts: 634
Joined: Sat 20 Mar 2010, 22:28

#121 Post by noryb009 »

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)

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#122 Post by jpeps »

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)
Simply incredible...

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#123 Post by jemimah »

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?
The "fat initrd" was pretty much a passing thing. 99% of the time a small initrd is used.

Image

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

I'm curious what architecture you would design to solve the bootable usb problem. You've got to keep the system as small as possible to fit on a small drive and still leave space for the user's files, and you need to avoid disk i/o as much as possble, both because it is slow and because writes cause wear on the drive. As far as I know puppy is the only system that is really designed to work well under these circumstances.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#124 Post by jpeps »

jemimah wrote: This is old but mostly still accurate:
http://puppylinux.com/development/howpuppyworks.html
jemimah, 2byte just posted that a few responses ago :)

Maybe a poll for how many people read it...

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

Re: Package management

#125 Post by jemimah »

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.

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.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

Re: Package management

#126 Post by jpeps »

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.
For starters, I'd like to see names in the builtin list that would match specs in the woof list.

noryb009
Posts: 634
Joined: Sat 20 Mar 2010, 22:28

#127 Post by noryb009 »

jpeps: People not voting doesn't mean that they don't care - it means they don't know about the thread or they don't understand enough about Puppy to vote. However, since you probably won't agree with my point of view, let's try it another way: please read through the beginner's help, and even the users, sections and see how many threads are simple "How do I install ___" or "updating ___ broke it". I haven't heard anyone ever say how Puppy's package management is good, outside the common packages of firefox, seamonkey, etc.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#128 Post by jpeps »

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

It means nothing...

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

Re: Package management

#129 Post by disciple »

2byte wrote:Package management.

I think we all agree that full super duper pm is not possible with puppy.
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?
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#130 Post by jemimah »

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.

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#131 Post by Lobster »

but I guess it didn't catch on
Joe's solution was simple, stable and just worked.
As an alchemist (one of my hobbies) I believe everything needs a little magic ingredient. :roll:
Joe may have needed a Raspberry Pi

. . . hey where is that slice? :wink:
http://puppylinux.org/wikka/PARM
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

2byte
Posts: 353
Joined: Mon 09 Oct 2006, 18:10

#132 Post by 2byte »

I do agree with noryb009 that the pet spec needs improving. But I don’t think it should be quite as drastic as the proposal. With build scripts in mind, the pet spec needs just the information required to reproduce the pet package and a dependencies list (other packages required for the pet to function). A recommends field would be nice. Anything more than that burdens the packager.
My 2 cents.
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?
The barriers? A different manager for each flavor of puppy? The lack of a complete package database, let alone one in the parent distro format. A package manager from the parent distro will have no clue about the majority of packages in puppy, nor does the current ppm. How could they when 2/3 of the data is missing? Not nonsense, fact. How is a general user to remove or update a package that was included in the woof-installed-files?
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.
There's another barrier. If the package manager is not in the ‘official’ puppy it is doomed.


User avatar
Moose On The Loose
Posts: 965
Joined: Thu 24 Feb 2011, 14:54

#133 Post by Moose On The Loose »

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

Image
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.

2byte
Posts: 353
Joined: Mon 09 Oct 2006, 18:10

#134 Post by 2byte »

Sorry jemimah, I didn't mean to ignore you.
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?
For me personally it would allow me to tailor, maintain, and upgrade the release of puppy that works best for me and my hardware for as long as I own that hardware. I was recently forced to purchase a new kit and believe it or not there are only two lunux releases that will work on it (given my skill set) and they are FatDog and the Slacko beta. Not Ubuntu, Mint, Antix, Mepis, and after a couple more I stopped. Puppy may be a hobby to some or even most but it is more than that to me. How long will FatDog and Slacko be maintained?
You can pull the package name, dependencies, origin, and related file list out of puppy's existing DB.
No you can't, unless I am very mistaken. Choose a package from the woof-installed-files list in the DB, how can you get that information for it using puppy?


User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#135 Post by jemimah »

Changing the package manager alone won't fix your problem. Someone would need to build the pets you are going to use to upgrade. Since you have made pet building more complex and annoying, you've simply created more work for the maintainer to do. Creating pets that will upgrade core components without breaking things is often more work than releasing a new version of a puplet.

---

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.

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#136 Post by jemimah »

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.
AUFS really only writes to the top layer. Splitting the writable layers is not really feasible. What you can do is setup puppy how you like, then convert the contents of your save file to a pet, which you could install if you needed to start over for some reason. It's generally better to save documents and such in a location outside the save file.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#137 Post by jpeps »

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.
Really? Try searching the various builtin names and let me know what the correct woof pet.spec is. The names could be easily searchable for the specific spec.

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#138 Post by jemimah »

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

Code: Select all

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

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#139 Post by jpeps »

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

Code: Select all

cat woof-installed-packages | egrep  ".*\|.*zip.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|"
This is a start, but still doesn't work for names like "bc". It also takes too long and still needs more filtering out for use in a script. I also don't know if the builtin is using the dev package or not. Why not just use specific names in the builtin list? Note that the script has to account for a name like "acl" referencing "libacl1" (or at least I think that's what it's referencing).

"ed" could be "libedit" or "libedit2", each with separate devs (or who knows what else).

Code: Select all

#!/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}"

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#140 Post by jemimah »

Sure it does

Code: Select all

cat woof-installed-packages |egrep  ".*\|bc\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|.*\|"
How long does this take for you?
real 0m0.008s
user 0m0.006s
sys 0m0.002s
There wouldn't be an aliases problem if you weren't using compat packages - maintaining our own repo allows us to have consistent package names. But you can get a list of aliases from /root/.packages/PKGS_MANAGEMENT.

I think the builtins are that way because it takes less space. Don't like it? Fix it.

Code: Select all

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

Post Reply