The State of Package Management
The State of Package Management
The current PET package format was created for Puppy 2.14. It was a great format, but over time, it has become more and more outdated. Today, PET the format has become almost useless and needs to be updated, without backward compatibility. The package specification is a guide line, packages are compressed in an inefficient way, and packages cannot be recreated.
The first problem is with the package specification: there isn't one. The specification is more of a guide line. Currently, the package should have a pet.specs file, but it's OK if it doesn't. This is not right, as the package manager has to assume the PET name includes the package name, version and release, and that the package doesn't have any dependencies. Another issue is that even when it has a pet.specs file, it doesn't include critical info such as the architecture, puppy it was built in, or who it was packaged by. This missing info causes many frustrations for end users. The specification needs to be changed and be more strict to avoid many common issues with PET packages.
The second problem is with the way it is packaged. Firstly, it is compressed as a .tar.gz file. A 214MB file can be compressed into a 85MB file. That's good, but xz can compress the same file into a 59MB file, which is 25MB (30%) smaller. If puppy used xz or something similar, the space and bandwidth needs of puppy's repositories would also be 30% smaller. Another issue with the format is that the files inside the package are in a folder, named the full package name (but not always), and sometimes with a "./" at the beginning. It also makes the pet.specs harder to find for scripts, especially if there is another file in the package called "pet.specs". Lastly, the packager is not currently needed to input a package release number or dependencies. These fields currently have almost no use, but without them, a package management system with upgrades and dependency tracking is almost impossible to write. All of puppy's packages should be packaged the same way.
Lastly, there is no way to recreate a PET. There are many reasons why you would want to know how a pet was compiled: compiling a new version of the package, trying to shrink the size of the package, or creating a new repository for a different architecture or puplet. Currently, you have to download the source code, and try to compile it. If there are any errors, you have to search for fixes. This method also looses any patches, enhancements or optimizations that are in the PET. If you are porting puppy to a new architecture, you have to do this for all of puppy's packages. A script based packager would allow for easy rebuilding of puppy packages. A script packager would read from a special file and create the package without human interaction. Puppy is the only distribution in distrowatch's top 10 that doesn't have a script based packager. A script based packager would simplify puppy's package management, and save a lot of time for packagers.
So, what has to be done? The PET system has to be forgotten, and a new format be created. While this would mean that many years of packages would become useless, it would allow puppy have a new start, without trying to balance old packages with new packages. The new format should not be specified by whoever creates the package manager, but by the packagers who will have to work with the new format. The specification should be strict, and be built to stand up to the test of time.
The first problem is with the package specification: there isn't one. The specification is more of a guide line. Currently, the package should have a pet.specs file, but it's OK if it doesn't. This is not right, as the package manager has to assume the PET name includes the package name, version and release, and that the package doesn't have any dependencies. Another issue is that even when it has a pet.specs file, it doesn't include critical info such as the architecture, puppy it was built in, or who it was packaged by. This missing info causes many frustrations for end users. The specification needs to be changed and be more strict to avoid many common issues with PET packages.
The second problem is with the way it is packaged. Firstly, it is compressed as a .tar.gz file. A 214MB file can be compressed into a 85MB file. That's good, but xz can compress the same file into a 59MB file, which is 25MB (30%) smaller. If puppy used xz or something similar, the space and bandwidth needs of puppy's repositories would also be 30% smaller. Another issue with the format is that the files inside the package are in a folder, named the full package name (but not always), and sometimes with a "./" at the beginning. It also makes the pet.specs harder to find for scripts, especially if there is another file in the package called "pet.specs". Lastly, the packager is not currently needed to input a package release number or dependencies. These fields currently have almost no use, but without them, a package management system with upgrades and dependency tracking is almost impossible to write. All of puppy's packages should be packaged the same way.
Lastly, there is no way to recreate a PET. There are many reasons why you would want to know how a pet was compiled: compiling a new version of the package, trying to shrink the size of the package, or creating a new repository for a different architecture or puplet. Currently, you have to download the source code, and try to compile it. If there are any errors, you have to search for fixes. This method also looses any patches, enhancements or optimizations that are in the PET. If you are porting puppy to a new architecture, you have to do this for all of puppy's packages. A script based packager would allow for easy rebuilding of puppy packages. A script packager would read from a special file and create the package without human interaction. Puppy is the only distribution in distrowatch's top 10 that doesn't have a script based packager. A script based packager would simplify puppy's package management, and save a lot of time for packagers.
So, what has to be done? The PET system has to be forgotten, and a new format be created. While this would mean that many years of packages would become useless, it would allow puppy have a new start, without trying to balance old packages with new packages. The new format should not be specified by whoever creates the package manager, but by the packagers who will have to work with the new format. The specification should be strict, and be built to stand up to the test of time.
Last edited by noryb009 on Tue 24 Jan 2012, 00:18, edited 1 time in total.
@noryb009
I am pretty dumb when it comes to pet packaging etc, but what you say makes sense. The only thing, you say that if we changed from .pet the previous packages won't work.
If your implementation was taken on board, does it have to not work? The old .pup files can often be made to work, why not .pets. It would be a shame to lose so much stuff.
From a strict user POV, I see the versioning and dependency part as being very useful. I am committed to using puppy, but I can see the frustration would piss off a lot of new users who like to click and it works. There have been many times I've clicked on a pet for something, and it doesn't work for whatever reason. For many that would be enough to hop off to another distro. If it were in the package to "know" if it wasn't going to work, and how to maybe make it work (dependencies) could be very helpful.
I am pretty dumb when it comes to pet packaging etc, but what you say makes sense. The only thing, you say that if we changed from .pet the previous packages won't work.
If your implementation was taken on board, does it have to not work? The old .pup files can often be made to work, why not .pets. It would be a shame to lose so much stuff.
From a strict user POV, I see the versioning and dependency part as being very useful. I am committed to using puppy, but I can see the frustration would piss off a lot of new users who like to click and it works. There have been many times I've clicked on a pet for something, and it doesn't work for whatever reason. For many that would be enough to hop off to another distro. If it were in the package to "know" if it wasn't going to work, and how to maybe make it work (dependencies) could be very helpful.
PET files can work with the new system, but they shouldn't. The main reasons are that it would slow down adoption of the new system, and it cause problems with dependencies and version tracking.If your implementation was taken on board, does it have to not work? The old .pup files can often be made to work, why not .pets. It would be a shame to lose so much stuff.
If the new system is successful, you wouldn't need a PET file to install a program. All the programs would either have a package available or have a build script. However, at the beginning this won't be the case, and using PET files may be necessary, but support has to drop after build scripts are created for most of the common programs.
Hi,
We should not forget that Puppy always tried to incorporate other packages (slackware, debs etc). The whole woof project was an attempt to draw on the repositories of other distros. It was not completely successful (but it was a success IMHO), because the puppy base is not 100% compatible with the other distros bases - so at some points there will be package conflicts / failures.
I observed that package management has given many people cause for turning to new directions - most recent examples:
1) Big Bass created TXZ puppy and now turned to Porteus which uses slackware packages.
2) Iguleder has created his own system of build scripts and repositories (also a woof-like system) and is now working on his own "fork" of puppy http://www.dimakrasner.com/drupal/,http://www.murga-linux.com/puppy/viewtopic.php?t=69248
3) Sickgut has his [url=ttp://www.murga-linux.com/puppy/viewtopic.php?t=69475]"Pussy" Linux[/url], which is a slimmed debian live system, but apt-get compatible to the debian stable repos.
4) Last. but not least Warry, Racy and now Saluki have all the same T2 base, so it is somehow a "back to the roots" - while they will not easily draw on a foreign repos they will have the ability to share many packages.
On one side I see the great benefits of either beeing 100% compatible to a foreign repo or creating a new "strict" Puppy package format, I have my doubts on the other side. Is it still a puppy if it is made 100% compatible to another distro? And will the puppy spirit remain the same if there are "not-puppy-like" strict rules for package creation and possibly a review process? Who would be "in charge"?
Becomming professional while keeping playfull and "childish" is a walk on a knifes edge.
I would vote for a backward compatible system, but it will be difficult to create. Becomming a downstream project of other distros (e.g. debian, like "Pussy") would be easiest, but: do we want that? And - last but not least - what does BK say
emil
We should not forget that Puppy always tried to incorporate other packages (slackware, debs etc). The whole woof project was an attempt to draw on the repositories of other distros. It was not completely successful (but it was a success IMHO), because the puppy base is not 100% compatible with the other distros bases - so at some points there will be package conflicts / failures.
I observed that package management has given many people cause for turning to new directions - most recent examples:
1) Big Bass created TXZ puppy and now turned to Porteus which uses slackware packages.
2) Iguleder has created his own system of build scripts and repositories (also a woof-like system) and is now working on his own "fork" of puppy http://www.dimakrasner.com/drupal/,http://www.murga-linux.com/puppy/viewtopic.php?t=69248
3) Sickgut has his [url=ttp://www.murga-linux.com/puppy/viewtopic.php?t=69475]"Pussy" Linux[/url], which is a slimmed debian live system, but apt-get compatible to the debian stable repos.
4) Last. but not least Warry, Racy and now Saluki have all the same T2 base, so it is somehow a "back to the roots" - while they will not easily draw on a foreign repos they will have the ability to share many packages.
On one side I see the great benefits of either beeing 100% compatible to a foreign repo or creating a new "strict" Puppy package format, I have my doubts on the other side. Is it still a puppy if it is made 100% compatible to another distro? And will the puppy spirit remain the same if there are "not-puppy-like" strict rules for package creation and possibly a review process? Who would be "in charge"?
Becomming professional while keeping playfull and "childish" is a walk on a knifes edge.
I would vote for a backward compatible system, but it will be difficult to create. Becomming a downstream project of other distros (e.g. debian, like "Pussy") would be easiest, but: do we want that? And - last but not least - what does BK say
![Question :?:](./images/smilies/icon_question.gif)
emil
- Lobster
- Official Crustacean
- Posts: 15522
- Joined: Wed 04 May 2005, 06:06
- Location: Paradox Realm
- Contact:
In Ye Olde Days, we Puppy users just made do with what we were given . . . Barry and others might compile a program, test it and say it was available.
Then the .pup was introduced as little more than a tar zip file
.pet which was considered overkill, is now the standard and very good too . . .
There is a way we can do this to avoid confusion
Use the new standard on ARM processors to start with
http://puppylinux.org/wikka/PARM
We could use .debs which are compressed if the PARM project becomes a Upup (similar to Lucid) or Dpup compile . . .
http://en.wikipedia.org/wiki/Deb_%28file_format%29
Are there advantages to having our own Puppy debs (optimised and junk removal offered)? Maybe so . . .
I believe Android, Apple and Ubuntu have got package manage right
scroll through packages. Install or uninstall.
How many packages should Puppy have?
All of them.
One other point; I did install a package in Saluki 008
- it was very well implemented. No need to restart x.
Maybe Jemimah will offer some tips . . .
Then the .pup was introduced as little more than a tar zip file
.pet which was considered overkill, is now the standard and very good too . . .
That extra 30% compression sounds yummyxz or something similar
There is a way we can do this to avoid confusion
Use the new standard on ARM processors to start with
http://puppylinux.org/wikka/PARM
We could use .debs which are compressed if the PARM project becomes a Upup (similar to Lucid) or Dpup compile . . .
http://en.wikipedia.org/wiki/Deb_%28file_format%29
Are there advantages to having our own Puppy debs (optimised and junk removal offered)? Maybe so . . .
I believe Android, Apple and Ubuntu have got package manage right
scroll through packages. Install or uninstall.
How many packages should Puppy have?
All of them.
One other point; I did install a package in Saluki 008
- it was very well implemented. No need to restart x.
Maybe Jemimah will offer some tips . . .
the quality of the package is down to the compiler's knowledge and skill.
IMO There are two puppy ideas which can re-enforce each other-
(A) to create a simple easy-to-use slimline OS which is hassle free
(B) to create an OS which people can experiment and learn development techniques
----
So how could this work? here's an example-
You say NO thanks I only want Packages that are known to work and tested - I don't want to be messing around in config files, using terminal etc.
In case (B)-
You say YES okay, if I know the author I will alert him/her to their nooby mistake.
---
Another way to manage quality is have a page for PETs where they can be rated by uses, like wordpress does-
http://wordpress.org/extend/plugins/sopa-blackout/
---
C) is there any technical reason why different compression techniques can't be used in Packages - including XZ.
---
D) what about SFS I've had a lots of trouble using these. Including breaking CUPS and messing up fonts.
![Arrow :arrow:](./images/smilies/icon_arrow.gif)
IMO There are two puppy ideas which can re-enforce each other-
(A) to create a simple easy-to-use slimline OS which is hassle free
(B) to create an OS which people can experiment and learn development techniques
----
So how could this work? here's an example-
In case (A)-When you load a PET file it is verified against certain standards.
It fails, for example if PET spec file is missing, then a warning is given 'Package may be non standard (pet-spec file missing) load anyway'?
You say NO thanks I only want Packages that are known to work and tested - I don't want to be messing around in config files, using terminal etc.
In case (B)-
You say YES okay, if I know the author I will alert him/her to their nooby mistake.
---
Another way to manage quality is have a page for PETs where they can be rated by uses, like wordpress does-
http://wordpress.org/extend/plugins/sopa-blackout/
---
C) is there any technical reason why different compression techniques can't be used in Packages - including XZ.
---
D) what about SFS I've had a lots of trouble using these. Including breaking CUPS and messing up fonts.
![Arrow :arrow:](./images/smilies/icon_arrow.gif)
The State of Package Management
DELETED!
Last edited by RSH on Wed 25 Jan 2012, 00:45, edited 1 time in total.
tar has got the -J, --xz option and it might be not too difficult to implement it into petget .
tar also has got the --backup[=CONTROL] backup before removal, choose version CONTRO=t, numbered make numbered backups
which i have already implemented at one puppy installation .
.pxz .pet2 .peto .peta would give a larger variety to compress ... something to chew on the code .
pxz would be a large step , bzip2 would be the next step after gzip .
*
I would also like the idea of a pre-install.sh .
It is possible to install to /tmp first and let the post-install.sh do the rest , but i have not seen it much .
*
It would be convenient to offer a second button in the Xdialog asking to install : DO YOU WANT TO LOOK INTO THE PET FIRST ?
IF yes then cp pet /tmp ;pet2tgz pet; tar xzf tarredpet; rox /tmp; fi;exit
tar also has got the --backup[=CONTROL] backup before removal, choose version CONTRO=t, numbered make numbered backups
which i have already implemented at one puppy installation .
.pxz .pet2 .peto .peta would give a larger variety to compress ... something to chew on the code .
pxz would be a large step , bzip2 would be the next step after gzip .
*
I would also like the idea of a pre-install.sh .
It is possible to install to /tmp first and let the post-install.sh do the rest , but i have not seen it much .
*
It would be convenient to offer a second button in the Xdialog asking to install : DO YOU WANT TO LOOK INTO THE PET FIRST ?
IF yes then cp pet /tmp ;pet2tgz pet; tar xzf tarredpet; rox /tmp; fi;exit
Making stricter rules for package creation isn't really for the developers, it's for the end users who rely on PET files to get their software.And will the puppy spirit remain the same if there are "not-puppy-like" strict rules for package creation and possibly a review process? Who would be "in charge"?
The puppy spirit will remain alive, but it's hard to tell. Stricter rules wouldn't effect the packager too much - it would just be a slightly different way of compressing the program. There will be lots of work to do for the developers, there is always tweaks to be done to packages and bytes to trim.
It is a good idea (.tar.gz with an md5 sum on the end, with package specifications inside), but it hasn't been used correctly (mostly the dependency field), and has become outdated..pet which was considered overkill, is now the standard and very good too...
It would be great to start on ARM with a new package format, but it could also slow things down considerably. It would be better to support both (and x86_64 also?) from the beginning, as it would allow everyone to contribute.Use the new standard on ARM processors to start with
We could use another package format, but I don't know if it would "work" for puppy, mostly due to puppy's size commitments.We could use .debs which are compressed if the PARM project becomes a Upup (similar to Lucid) or Dpup compile...
People should definitely be able to submit bugs to the packager, but I think rating would work well. Packages either work or they don't, and if they don't, they should be fixed.Another way to manage quality is have a page for PETs where they can be rated by uses, like wordpress does
As far as I know, there isn't any real technical reason. The packages just wouldn't work on puplets before support was added.C) is there any technical reason why different compression techniques can't be used in Packages - including XZ.
I think the best way for SFS to be handled is to remove them from online repositories and let users generate their own from multiple large packages. SFSes are great if you need some programs in a lot of puppies which are installed frugally, but they are horrible for full installs, or if you run into the SFS limit. Having users generate their own would let them decide what they want and remove the rest, instead of some of the "theme" SFSes, which have many packages you don't need. It doesn't make sense to have to host 2 copies of packages (PET and SFS) either.D) what about SFS I've had a lots of trouble using these. Including breaking CUPS and messing up fonts.
Packages shouldn't touch files that don't belong to them, though. There could be scripts that need that special version of the file - it's bad if you are locked out of puppy because you installed a package that moved a library that bash needs. This also causes multiple copies of files, which can add up quickly if you have limited disk space.tar also has got the --backup[=CONTROL] backup before removal, choose version CONTRO=t, numbered make numbered backups
I don't see why we should use bzip2 because it's the "next step". XZ has a better compression ratio, so why should we have to go through the trouble of changing the standard twice, resulting in more backward compatibility code?pxz would be a large step, bzip2 would be the next step after gzip.
I would also like a better package install/remove format, which the pinstall.sh and puninstall.sh, along with any new scripts, are in one file, which would allow them to share code. The file would just have functions pinstall(), puninstall()... or something.I would also like the idea of a pre-install.sh.
I think that anyone who wants to look into a PET file would know how to extract it manually. Every user shouldn't have to click "no" every time they install something to save developers a few seconds.It would be convenient to offer a second button in the Xdialog asking to install : DO YOU WANT TO LOOK INTO THE PET FIRST?
Changing the type of compression used won't help the mess at all -it'll just make it possible to fit more mess in less space. A working package format specification *is* a lot trouble for packagers -unless the package spec is accompanied by tools which make it possible to create packages which conform to the spec -preferably easily.
src2pkg provides the tool which includes the tricks needed to make packages smaller, etc. My new 'tpkg' package format provides all the extra stuff needed to permit depends resolution, verification of each file installed, sane upgrade/removal of any package, authorization of package builder and lots more. All that is provided automatically by src2pkg -even dependency resolution for script programs.
src2pkg provides the tool which includes the tricks needed to make packages smaller, etc. My new 'tpkg' package format provides all the extra stuff needed to permit depends resolution, verification of each file installed, sane upgrade/removal of any package, authorization of package builder and lots more. All that is provided automatically by src2pkg -even dependency resolution for script programs.
Quote:
tar also has got the --backup[=CONTROL] backup before removal, choose version CONTRO=t, numbered make numbered backups
Packages shouldn't touch files that don't belong to them, though. There could be scripts that need that special version of the file - it's bad if you are locked out of puppy because you installed a package that moved a library that bash needs. This also causes multiple copies of files, which can add up quickly if you have limited disk space.
Quote:
pxz would be a large step, bzip2 would be the next step after gzip.
I don't see why we should use bzip2 because it's the "next step". XZ has a better compression ratio, so why should we have to go through the trouble of changing the standard twice, resulting in more backward compatibility code?
Quote:
I would also like the idea of a pre-install.sh.
I would also like a better package install/remove format, which the pinstall.sh and puninstall.sh, along with any new scripts, are in one file, which would allow them to share code. The file would just have functions pinstall(), puninstall()... or something.
Quote:
It would be convenient to offer a second button in the Xdialog asking to install : DO YOU WANT TO LOOK INTO THE PET FIRST?
I think that anyone who wants to look into a PET file would know how to extract it manually. Every user shouldn't have to click "no" eve
ry time they install something to save developers a few seconds.
Code: Select all
--- /mnt/+JUMP-6+luci-218.sfs/usr/local/petget/petget 2010-06-16 14:33:36.000000000 -0100
+++ /usr/local/petget/petget 2012-01-27 13:59:02.000000000 -0100
@@ -17,6 +17,8 @@
[ ! $1 ] && exit
+mkdir -p /tmp/PetGet ##+++2011_10_25
+
export LANG=C
. /etc/DISTRO_SPECS #has DISTRO_BINARY_COMPAT, DISTRO_COMPAT_VERSION
@@ -153,14 +155,21 @@ export INSTALL_DIALOG="<window title=\"P
<text use-markup=\"true\"><label>\"<b>${FULLPKGNAME}</b>\"</label></text>
<hbox>
<button ok></button>
+ <button><label>Examine Package</label>
+ <action>EXIT:examine</action></button>
<button cancel></button>
</hbox>
</vbox>
- </window>"
+ </window>"
RETPARAMS="`gtkdialog3 --program=INSTALL_DIALOG`"
eval "$RETPARAMS"
-[ "$EXIT" != "OK" ] && exit
+#echo $EXIT
+echo $RETPARAMS
+echo $EXIT
+if [ "$EXIT" != "OK" -a "$EXIT" != "examine" ];then # && exit
+echo "exiting $0";exit;fi
+if [ "$EXIT" = "OK" ];then
#find entry in databases...
#pkgname|nameonly|version|pkgrelease|category|size|path|fullfilename|dependencies|description|
#optionally on the end: compileddistro|compiledrelease|repo| (fields 11,12,13)
@@ -181,9 +190,9 @@ fi
[ "$originPKGPATH" = "$PKGPATH" ] && cp -f ${PKGPATH}/${FULLPKGNAME} ${PKGPATH}/${FULLPKGNAME}-TEMPBACKUP
#install pkg...
-rm -f /tmp/petget_missing_dbentries-Packages-* 2>/dev/null
-rm -f /tmp/petget-installed-pkgs-log 2>/dev/null
-echo "$DB_ENTRY" > /tmp/petget_missing_dbentries-Packages-alien
+rm -f /tmp/PetGet/petget_missing_dbentries-Packages-* 2>/dev/null
+rm -f /tmp/PetGet/petget-installed-pkgs-log 2>/dev/null
+echo "$DB_ENTRY" > /tmp/PetGet/petget_missing_dbentries-Packages-alien
/usr/local/petget/installpkg.sh $PKGPATH/$FULLPKGNAME
RETVAL=$?
@@ -195,7 +204,7 @@ rm -f $PKGPATH/${PKGNAME}.tar.gz 2>/dev/
[ "$originPKGPATH" = "$PKGPATH" ] && mv -f ${PKGPATH}/${FULLPKGNAME}-TEMPBACKUP ${PKGPATH}/${FULLPKGNAME}
#announce result...
-if [ $RETVAL -ne 0 -o ! -s /tmp/petget-installed-pkgs-log ];then
+if [ $RETVAL -ne 0 -o ! -s /tmp/PetGet/petget-installed-pkgs-log ];then
export FAIL_DIALOG="<window title=\"Puppy Package Manager\" icon-name=\"gtk-about\">
<vbox>
<pixmap><input file>/usr/local/lib/X11/pixmaps/error.xpm</input></pixmap>
@@ -204,12 +213,12 @@ if [ $RETVAL -ne 0 -o ! -s /tmp/petget-i
<button ok></button>
</hbox>
</vbox>
- </window>"
+ </window>"
gtkdialog3 --program=FAIL_DIALOG
exit
fi
-INSTALLEDMSG="`cat /tmp/petget-installed-pkgs-log`"
+INSTALLEDMSG="`cat /tmp/PetGet/petget-installed-pkgs-log`"
MENUMSG=""
INSTALLEDCAT="`echo -n "$INSTALLEDMSG" | rev | cut -f 1 -d ' ' | rev`"
if [ "$INSTALLEDCAT" = "none" ];then
@@ -218,7 +227,7 @@ else
MENUMSG="<text><label>...look in '${INSTALLEDCAT}' in the menu (bottom-left of screen) to run the application.</label></text>"
fi
-#installpkg.sh will have logged to /tmp/petget-installed-pkgs-log
+#installpkg.sh will have logged to /tmp/PetGet/petget-installed-pkgs-log
export INSTALL_DIALOG="<window title=\"Puppy Package Manager\" icon-name=\"gtk-about\">
<vbox>
<pixmap><input file>/usr/local/lib/X11/pixmaps/ok.xpm</input></pixmap>
@@ -256,4 +265,32 @@ fi
kill $X3PID
+else
+#PKGPATH="`dirname "$PASSEDPARAM"`"
+#FULLPKGNAME="`basename "$PASSEDPARAM"`"
+#PASSEDBASE="`basename "$PASSEDPARAM"`"
+FULLPKG="${FULLPKGNAME%\.*}";echo $FULLPKG
+EXTN="${FULLPKGNAME##*.}";echo $EXTN
+mkdir -p /tmp/"$FULLPKG"
+cp "$PKGPATH/$FULLPKGNAME" /tmp/"${FULLPKG}"/
+cd /tmp/"${FULLPKG}"/
+case $EXTN in
+pet)
+pet2tgz ${FULLPKGNAME}
+tar xzf ${FULLPKG}.tar.gz
+rox /tmp/"${FULLPKG}"/
+xmessage -buttons "OK :140, Delete:141" "Click Delete button to erase this
+examination directory ,
+otherwise just OK"
+if [ "$?" = '141' ];then
+rox -D /tmp/"${FULLPKG}"/
+rm -rf /tmp/"${FULLPKG}"/
+fi
+;;
+*)
+xmessage -bg red "$EXTN examination not yet implemented"
+;;
+esac
+exec petget "$PASSEDPARAM"
+fi
###END###
If the PPM is to be changed, are we bound to consult Barry K, or is this all part of the community's ability to sustain itself and continue growing, whilst giving him breathing space/time?
I like the idea of improving the package manager, as I have to admit to not having the skillset to resolve problems if and when they occur....I just try something else, or accept it , if it doesn't work - Package management overhaul seems overdue since 2.14 or so
I think the most frustrating thing is the end-user inability to find out what to do IF something doesn't install, or if something is uninstalled, something else breaks - where are the on-screen help messages?
I had hoped SFSs were going to provide a solution, but not so far
I have to say, the people showing most promise, from my limited perspective are amigo, iguleder, technosaurus, big_bass, [though he may have moved on], and jemimah [apologies if I haven't noticed your skills/mentioned you]
I would love puppy to become a distro which uses a minimalist full feature kernel, [or instructions how to modify it], with a packaging setup that allowed me to install ANY suitable source code, and make it puppy compatible, with dependency hell taken care of automatically, or install a ready built program/dotpet/SFS knowing which kernel it will work with and letting me know if it isn't suitable, whilst telling me what to find that IS suitable!
...and which could be updated/maintained using a standard linux format filesystem, AND that could be transferred to a different hardware base - ARM/PPC, IF I so chose
.....are we at least working towards it?
or still going in separate directions?
Perhaps a few explanations about essentials like gcc, libc and gtk versions, static/dynamic builds, compressions, filesystems etc [I think...?] would help end users understand the problems a bit, and not have such high expectations....it's not, after all, my intention to put devs under pressure....but I don't know what else I can do to help, other than the research, posting and ideas offered that I already do
Are puppy/linux devs aware of a linux equivalent of a program I used back in win98 days called Dependency Walker?
I posted a link for jemimah recently which looked similar
http://www.murga-linux.com/puppy/viewto ... 868#598868
I think we are amazingly lucky really that puppy works as well as it does, considering the sheer lack of standardised process control in place, in both puppy and linux in general!
- thanks Barry/devs!
Has anyone ever done a sequence diagram/flow chart of puppy so we might know what it ought to be doing? [headings, with features/functions would do?]
I know grub got discussed, but again, I don't recall a final collated version....
My current biggest problem isn't puppy, AT ALL, ...... it's finding a browser/flash combination that is usable AND crash-free, which lets me browse/search/email etc, yet doesn't encroach on my freedom and collate my browsing lifestyle for some snoop/corporation/FBI to use against me !!
Aitch![Smile :)](./images/smilies/icon_smile.gif)
I like the idea of improving the package manager, as I have to admit to not having the skillset to resolve problems if and when they occur....I just try something else, or accept it , if it doesn't work - Package management overhaul seems overdue since 2.14 or so
I think the most frustrating thing is the end-user inability to find out what to do IF something doesn't install, or if something is uninstalled, something else breaks - where are the on-screen help messages?
I had hoped SFSs were going to provide a solution, but not so far
I have to say, the people showing most promise, from my limited perspective are amigo, iguleder, technosaurus, big_bass, [though he may have moved on], and jemimah [apologies if I haven't noticed your skills/mentioned you]
I would love puppy to become a distro which uses a minimalist full feature kernel, [or instructions how to modify it], with a packaging setup that allowed me to install ANY suitable source code, and make it puppy compatible, with dependency hell taken care of automatically, or install a ready built program/dotpet/SFS knowing which kernel it will work with and letting me know if it isn't suitable, whilst telling me what to find that IS suitable!
...and which could be updated/maintained using a standard linux format filesystem, AND that could be transferred to a different hardware base - ARM/PPC, IF I so chose
.....are we at least working towards it?
or still going in separate directions?
Perhaps a few explanations about essentials like gcc, libc and gtk versions, static/dynamic builds, compressions, filesystems etc [I think...?] would help end users understand the problems a bit, and not have such high expectations....it's not, after all, my intention to put devs under pressure....but I don't know what else I can do to help, other than the research, posting and ideas offered that I already do
Are puppy/linux devs aware of a linux equivalent of a program I used back in win98 days called Dependency Walker?
I posted a link for jemimah recently which looked similar
http://www.murga-linux.com/puppy/viewto ... 868#598868
I think we are amazingly lucky really that puppy works as well as it does, considering the sheer lack of standardised process control in place, in both puppy and linux in general!
![Laughing :lol:](./images/smilies/icon_lol.gif)
Has anyone ever done a sequence diagram/flow chart of puppy so we might know what it ought to be doing? [headings, with features/functions would do?]
I know grub got discussed, but again, I don't recall a final collated version....
![Sad :(](./images/smilies/icon_sad.gif)
My current biggest problem isn't puppy, AT ALL, ...... it's finding a browser/flash combination that is usable AND crash-free, which lets me browse/search/email etc, yet doesn't encroach on my freedom and collate my browsing lifestyle for some snoop/corporation/FBI to use against me !!
Aitch
![Smile :)](./images/smilies/icon_smile.gif)
The PPM shouldn't be changed, it should be removed. Changing PPM would either make a few features impossible to implement, or cause some scripts to not work right.If the PPM is to be changed
You might find a browser/flash combination that works, but it wouldn't be possible to recreate the package. A script based packager would allow previous workarounds and patches to be recorded and used again.My current biggest problem isn't puppy, AT ALL, ...... it's finding a browser/flash combination that is usable AND crash-free, which lets me browse/search/email etc
There is currently no way to know what is in the packages you download, unless you compile it yourself. You don't know if the packager added something malicious to the code (random people post PETs on this forum), or if somebody switched the packages on the server (packages aren't signed). This is another big problem with the package system currently used.yet doesn't encroach on my freedom and collate my browsing lifestyle for some snoop/corporation/FBI to use against me !!
Just wanted to post this:
(link)tytower wrote:I uninstalled all that i had downloaded.
However while it was removing those it also deleted all shared objects files so now I don't have a lot of standard library files there that should be !!
Surely such a basic as not deleting shared objects CAN'T be overlooked but it is in 5.3
The problem isn't the ppm, it's the repos.
If J. Random User picks some random package from the Ubuntu repo, downloads 300MB worth of deps overwriting system files in the process, what do you think is going to happen?
Or if J Random User downloads some random package from some random puppy site, probably not even meant for his/her version of puppy, any wonder why it's difficult to track down the dependencies?
The only way any of this works at all is if puppy developers compile and test the packages, and specify the dependencies correctly, and if the users stick to installing stuff from the tested repositories only.
Puppy is a pint-sized and very finicky OS. Trying to use packages from other repos is asking for trouble.
If J. Random User picks some random package from the Ubuntu repo, downloads 300MB worth of deps overwriting system files in the process, what do you think is going to happen?
Or if J Random User downloads some random package from some random puppy site, probably not even meant for his/her version of puppy, any wonder why it's difficult to track down the dependencies?
The only way any of this works at all is if puppy developers compile and test the packages, and specify the dependencies correctly, and if the users stick to installing stuff from the tested repositories only.
Puppy is a pint-sized and very finicky OS. Trying to use packages from other repos is asking for trouble.
I completely agree. The only reason why Puppy uses other repos is because we can't organize a package system of our own that works.Puppy is a pint-sized and very finicky OS. Trying to use packages from other repos is asking for trouble.
Like you say, the PET format works in theory, but it is bad in reality. We could change the way things are packaged, but the backwards compatibility requirement would cause packages to not hold architecture info, have XZ (or similar) compression and wouldn't allow packages to be named depending on what it is (firefox from git should be called "firefox-git", but it wouldn't be seen if a package needs "firefox"). A new package format would give packagers a new start with a modern package specification.The only way any of this works at all is if puppy developers compile and test the packages, and specify the dependencies correctly, and if the users stick to installing stuff from the tested repositories only.
.
I have repeated many times... Stop making Pets and make SFS files instead.
There`s not nearly as many problems and the ones SFS`s do have are small.
But they must be built and labeled for the Puppy version they`re intended.
The SFS manager should ID the SFS files by this, so that way no problems.
I have tried sooo many pets that don`t work, that I won`t install them now.
SFS files don`t install, so nothing to remove, and they don`t use Save file.
A new install of Puppy, choose the Web Browser and it takes up Save space!
My vote... Just use SFS files for Puppy`s standard file package format.
.
I have repeated many times... Stop making Pets and make SFS files instead.
There`s not nearly as many problems and the ones SFS`s do have are small.
But they must be built and labeled for the Puppy version they`re intended.
The SFS manager should ID the SFS files by this, so that way no problems.
I have tried sooo many pets that don`t work, that I won`t install them now.
SFS files don`t install, so nothing to remove, and they don`t use Save file.
A new install of Puppy, choose the Web Browser and it takes up Save space!
My vote... Just use SFS files for Puppy`s standard file package format.
.
Last edited by sunburnt on Sun 29 Jan 2012, 19:21, edited 1 time in total.
- Lobster
- Official Crustacean
- Posts: 15522
- Joined: Wed 04 May 2005, 06:06
- Location: Paradox Realm
- Contact:
Sardines! [Lobsterian cussing]Puppy is a pint-sized and very finicky OS. Trying to use packages from other repos is asking for trouble.
Jemimah is right. However that is exactly what we are doing with Woof2
and BarryK is right too. Oh boy . . .
![Confused :?](./images/smilies/icon_confused.gif)
With P-ARM (Puppy on ARM)
http://puppylinux.org/wikka/PARM
the first thing that will be available is the devx.sfs
What will come next?
A Quickpet/Slickpet?
PPM?
or perhaps a wiki page of available software as used in Slacko?
http://puppylinux.org/wikka/SlackoNews
My inclination is to have a firefox.ap (as an example)
conservative format
What would .ap be?
Basically a pet compiled on ARM (Arm Pet) with Puppy
that could be used in the PPM.
What would be the difference?
The name change moves us into the world of apps
(which is very easy for end users)
More efficient compression would be possible
Would the .ap be similar to an SFS (contain any dependencies and therefore be safe to remove)?
. . . up to developers
![Smile :)](./images/smilies/icon_smile.gif)
Puppy2012
You ain't seen nothing yet . . .
Last edited by Lobster on Sun 29 Jan 2012, 14:25, edited 1 time in total.
SFS files do have many advantages over other package formats, including not having to decompress them and including dependencies.I have repeated many times... Stop making Pets and make SFS files instead.
However, SFS files do have problems. These include having to have a save file to install them (maybe not anymore, there at least 1 project trying to fix this), you can't uninstall them in a full install, and having a limited number that you can install.There`s not nearly as many problems and the ones SFS do have are small.
The biggest problem is the limited number you can install. People have tried to avoid this in the past by creating theme SFSes, like graphics and multimedia. This lowers the amount of SFSes you need for your needed programs, but gives you a lot of unneeded programs.
I think SFS files could be useful if we allow users to make their own. This allows users to include what they want (without extra programs that they will never use), and makes it for their puppy version (which can be hard to find online).
The developers that work on Puppy are here because we find simplicity attractive. Puppy is, in every aspect, 'the simplest thing that could possibly work.' Developers who like systems that are complex and robust have sensibly moved on to support "real" distros. The ones who love the beauty of simplicity remain.noryb009 wrote:I completely agree. The only reason why Puppy uses other repos is because we can't organize a package system of our own that works.Puppy is a pint-sized and very finicky OS. Trying to use packages from other repos is asking for trouble.
Like you say, the PET format works in theory, but it is bad in reality. We could change the way things are packaged, but the backwards compatibility requirement would cause packages to not hold architecture info, have XZ (or similar) compression and wouldn't allow packages to be named depending on what it is (firefox from git should be called "firefox-git", but it wouldn't be seen if a package needs "firefox"). A new package format would give packagers a new start with a modern package specification.The only way any of this works at all is if puppy developers compile and test the packages, and specify the dependencies correctly, and if the users stick to installing stuff from the tested repositories only.
When you dig a little, nearly every single feature of puppy is too simplistic to be reliable enough, flexible enough, or secure enough for all but the most basic use cases. That simplicity is Puppy's only endearing feature. Complicate it, and you just have another yet another sucky os that doesn't stand out.
The problem isn't the pet format (though xz could probably be added by changing only like 3 lines of code). The problem is, as you say, that "we can't organize". You can count the number of active puppy developers on two hands, and the ones who are real artists with a compiler can probably be counted on one. Brains cannot be replaced with code.
What we have now with woof is the best it gets if you attempt to automate away the developers job. Complicating it, will only steepen the learning curve. Increase the workload of the existing devs, and less will get done, not more.
I've attempted to design Saluki in such a way that it facilitates developer cooperation as much as possible. When it's ready, I will open up the repo to multiple maintainers and hopefully we can maintain a high standard of quality for packages. I do believe this is the only practical way forward.