disentangle petget from the gui

[technosaurus]

This is a first step to allow any kind of meaningful improvement to the ppm GUI The following should be implemented: petget --help petget --list [category] - list all packages in current package list or only specified categorie{s} petget --setpkglist - $HOME/.packages/Packages-* petget --setrepo url -sets the default repository to url etc... and last but not least petget install package-name That has to be the most ridiculous thing to be missing

[jamesbond3142]

In Fatdog64 600 series which still used the PET format, I've created something like this called silent_petget. It is fully compatible with PET specification circa Puppy 4.1.x. It's 185 lines including comments, supports xz/bzip2/gz pets, but only support pets (not debs, tgz, txz, etc); and is meant to be used from CLI. It doesn't support dependencies. I haven't never tested it with the new petspecs (which contains versioned dependencies, etc). Feel free to grab it and use it as a base if you're interested here (login required).

[technosaurus]

This is probably going to sound like a rant because there is so much wrong with the whole setup by virtue of things just being a series of bolted fixes consisting of whatever way happened to work to solve the current problem. I'll go file by file to make it somewhat coherent

DISTRO_PET_REPOS WTF - who the hell can decipher that garbage change format to: Packages-.pet|default repo url|mirror1|mirror2|...|mirror# Packages-.txz|default repo url|mirror1|mirror2|...|mirror# Packages-.deb|default repo url|mirror1|mirror2|...|mirror#

PACKAGELISTS_PET_ORDER is simply determined by the pkglist order This would allow a simple script to programatically run time wget $REPO/$PackageList to check update it to the fastest repo and reorder it to: Packages-.pet|fastest mirror|default repo url|mirror1|mirror2|...|mirror# Packages-.txz|fastest mirror|default repo url|mirror1|mirror2|...|mirror# Packages-.deb|fastest mirror|default repo url|mirror1|mirror2|...|mirror#

DISTRO_COMPAT_REPOS superfluous, just add it to the hierarchy above

PKGS_HOMEPAGES move to the pkg database

PKGS_MANAGEMENT already in pkg database

now for the databases

915resolution-0.5.3-patched20110617-x86_64|915resolution|0.5.3-patched20110617-x86_64|||||915resolution-0.5.3-patched20110617-x86_64.pet|...

• 915resolution-0.5.3-patched20110617-x86_64 is just field1+field2
• 915resolution-0.5.3-patched20110617-x86_64.pet is just field1+field2 +pkg type specified in the

Then there is the category field. Just blatantly copy the Categories= field from the desktop file (if no desktop file then it is a building block, dev, doc or nls). Then use a case statement to pull in the various categories according to /etc/xdg/menus/hierarchy example:

case "$Categories" in
*X-Fun*|*Game*|*Amusement*|*BlocksGame*|*KidsGame*|*Simulation*|*X-Fun-adventure*|*ActionGame*|*AdventureGame*|*RolePlaying*|*X-Fun-boardgame*|*BoardGame*|*X-Fun-cardgame*|*CardGame*|*X-Fun-puzzle*|*StrategyGame*|*LogicGame*|*X-Fun-shooter*|*X-Fun-arcade*|*ArcadeGame*)Category=Fun;;
esac

or better yet add a category and subcategory field that matches up with its menu placement, so that we only have to do this once when the package database is built ... on a full rewrite we could replace the 1st field with the categories and the full filename field with the subcategory, but for now just add them to the end

and then there is localization I already talked about using the .desktop file for the Categories field, but really we should probably keep all of the fields in the .desktop files in the database (wouldn't it be nice to be able to display each program's icon in the package manager if it is available) For fields with a localized version (such as Name[fr]=) we should generate database entries and a separate package list for each language so that it can be included before the main package list in DISTRO_PET_REPOS

Then there is the database parsing itself ... OMG its horrible Just do this:

IFS="|"
while read Field1 Field2 ... FieldN; do
#stuff with fields - there should be no cuts, greps, seds etc...
done < pkgdbFile

Now we get to petget. may as well start from scratch

#!/bin/sh
petget_usage(){ :todo; exit; }
petget_list(){ :list packages with filtering; }
petget_install_deb(){ :todo; }
petget_install_tgz(){ :todo; }
petget_install_pet(){ :todo; }
petget_install(){ :parse package files, download and install; }
petget_remove(){ :todo; }
#petget_$SomeAction(){ } ... etc and so forth
case "$1" in
  ""|-h|--help)petget_usage;;
  install|remove|list)Action=$1;shift;petget_${Action} $@;;
  -*)[ -f "${1:1}" ] && petget_remove "${1:1}" || petget_usage;;
  *)[ -f "$1" ] && petget_install_${1##*.} "$1";;

ppm see above comment on reading puppy database files see above comment on using .desktop files to generate the database: see above comment on using subcategories ... it really needs them for larger distros see above comment on localization each package should use its own icon if available, then fall back to an icon for one of its entries in Categories followed by the subcategory icon and then the category icon the (localized) description for each package should be a tooltip (I am currently implementing this for jwm too - menu tooltips were added to jwm recently)

[wdlkmpx]

In the pkg database I see there are 13 fields. So, mister technosaurus, which of the 13 fields should remain? and in what order?

function Puppy2Info() {
    local specs="$@"
    pkginfo=${specs//||/|~|}
    pkginfo=${pkginfo//||/|~|}
    SFI=$IFS
    IFS='|'
    x=1
    for field in $pkginfo ; do
        [ "$field" = "~" ] && field=''
        case $x in
            #1) [ "$field" ] && echo pkgname=${field}       ;;
            2) [ "$field" ] && echo nameonly=${field}       ;;
            3) [ "$field" ] && echo version=${field}        ;;
            4) [ "$field" ] && echo pkgrelease=${field}     ;;
            5) [ "$field" ] && echo category=${field}       ;;
            6) [ "$field" ] && echo size=${field}           ;;
            7) [ "$field" ] && echo path=${field}           ;;
            8) [ "$field" ] && echo fullfilename=${field}   ;;
            9) [ "$field" ] && echo dependencies=${field}   ;;
            10) [ "$field" ] && echo description=${field}   ;;
            11) [ "$field" ] && echo compileddistro=${field};;
            12) [ "$field" ] && echo compiledrelease=${field};;
            13) [ "$field" ] && echo repo=${field}          ;;
        esac
        let x++
    done
    IFS=$SFI    
}

[mavrothal]

In the current PPM design they are all needed and in the specific order since other PPM scripts look at those. When/if a new designed is implemented, should be reevaluated accordingly.

A general notion, not related directly to the above As far as I am concerned hackability is a major characteristic of puppy and to a great extend is based on its extensive use of scripts that are not "too professional". Would be useful to sacrifice readability/hackability to really gain performance. ie in loops repeating thousands of times as is the dependency searches or database transformation for example, where few milliseconds differences per cycle can translate in several seconds. Would be wrong to sacrifice readability/hackability to gain few milliseconds total cpu time or just style, and alienate the novice that is trying to get his/her hands dirty. I should not be expected to pull these kind of patches, but others please do as you see fit.

Of course style patches that improve the at times horrible style (indentation, line length etc) are always welcome.

[technosaurus]

Here is an awesome little chunk of code that would significantly speed up package file parsing (or anything in a tabular format)

#usage:  get_vars "separator" Var1 ... VarN (no $, just the variable name)
get_vars(){
    local IFS="$1"
    shift
    read $@
}

#example usage
for packageFile in $HOME/.packages/Packages-*; do
    while get_vars "|" pkgname nameonly version pkgrelease category size path fullfilename dependencies description compileddistro compiledrelease repo junk; do
        echo "________________________________________________________________________________
        pkgname=$pkgname
        nameonly=$nameonly
        version=$version
        pkgrelease=$pkgrelease
        category=$category
        size=$size
        path=$path
        fullfilename=$fullfilename
        dependencies=$dependencies
        description=$description
        compileddistro=$compileddistro
        compiledrelease=$compiledrelease
        repo=$repo
        "
    done < "$packageFile"
done

[wdlkmpx]

I think a parallel petget implementation can be done, some time ago, in order to make my remasters look like a pristine puppy, I wrote some functions for that purpose http://pastebin.com/Zd8c4Dk3

This is how I download and install deb files http://pastebin.com/LPV3TV4C

So taking pieces and bits from here and there, it can be done. I guess it's a matter of starting it

[01micko]

This still needs to be done and probably isn't too hard.

First problem is to fix the EDITOR.

--- removepreview.sh    2017-02-24 12:45:58.720230519 +1000
+++ /usr/local/petget/removepreview.sh  2017-02-27 20:14:04.427082658 +1000
@@ -116,12 +116,12 @@
  if [ "$DISPLAY" ];then
   /usr/lib/gtkdialog/box_ok "$(gettext 'Puppy package manager')" warning "<b>$(gettext 'No file named') ${DB_pkgname}.files $(gettext 'found in') /root/.packages/ $(gettext 'folder.')</b>" "$0 $(gettext 'refusing cowardly to remove the package.')" " " "<b>$(gettext 'Possible suggestions:')</b> $WARNMSG" "<b>$(gettext 'Possible solution:')</b> $(gettext 'Edit') <i>/root/.packages/user-installed-packages</i> $(gettext 'to match the pkgname') $(gettext 'and start again.')"
   rox /root/.packages
-  geany /root/.packages/user-installed-packages
+  $DEFAULTTEXTEDITOR /root/.packages/user-installed-packages
   exit 101
   ###+++2011-12-27 KRG
  else
   dialog --msgbox "$(gettext 'No file named ' ) ${DB_pkgname}.files $(gettext ' found. Refusing cowardly to remove the package. Possible solution: Edit /root/.packages/user-installed-packages and start again.')" 0 0
-  mp /root/.packages/user-installed-packages
+  $EDITOR /root/.packages/user-installed-packages
   exit 101
  fi
 fi

Then, there is a fatal bug that refuses to remove a package using the CLI...

The var is broken.. only giving $GENERIC_NAME.files as the file to search for in /root/.packages/user-installed-packages :weary:

I was actually looking for a neat solution to upgrade a package, which of course needs to uninstall the original then install the replacement.. but then went on to think that petget could be upgraded to work on the CLI and without X... thoughts?

[wdlkmpx]

Now i can certainly make things simpler and faster than 2 years ago when it comes to process fields. Misftire opened a thread with a cli petget, we can use that.

Puppy is fundamentally flawed and Not really modular due to the poor package management. Maybe if we use a fork of pacman then it will make sense, but it's really too late for everything, we should use mistfire's stuff.

And the gui should be simplified, there can't be two gui's. It always gave me headaches, but i might edit stuff, as no one else wiLl

[wdlkmpx]

The PPM is stuff of nightmares, everytime i look at the code i'm overwhelmed by negative feelings..

I think it's beyond help, the whole design is 'bad' to say the least, it has a nice gui, but all the underlying stuff is.. 'bad' to say the least.

When you see grep's and sed's all over the place you know you're dealing with extremely slow code.

This is ok for wary or for a distro that basically has nothing to offer in the package repos (and no dependency checking)..

From the beginning the pkgs or generic names had the wrong 'name', so PKGS_MANAGEMENT specifies a "translation" table. The PKGS_DBS and the PKGS_SPECS had this flaw. To fix this you have to delete pet pkgs until there is none.