names|n [PKG] list package name matches in the CURRENT repo
names-all|na [PKG] list package name matches in ALL repos

search|s [SEARCH] search all package info in CURRENT repo
search-all|sa [SEARCH] search all package info in ALL repos

repo|r [REPONAME] set repo to use, show current repo if none given
repo-info|ri REPONAME display the name, and other info of CURRENT repo
repo-list|rl list names of all available repositories
repo-update|ru [REPONAME] update the current repo package list
repo-convert|rc FILE convert repo files to pre/post Woof format

add-source add new repo (needs repo file in ~/.packages/)
update-sources update the list of available repos
repo-pkg-scope one|all search pkgs in current repo (one), or all (all)
repo-dep-scope one|all search deps in current repo (one), or all (all)
bleeding-edge no|yes if yes, get latest pkg versions, from ANY repo
recursive-dep-check no|yes get deps recursively (yes), or not (no)

dir2pet DIR create a pet package from a directory
dir2sfs DIR create an sfs package from a directory
dir2tgz DIR create a tar.gz file from a directory
deb2pet DEBFILE convert local deb file to a pet package
pet2sfs PETFILE convert local pet file to an sfs package
pet2tgz PETFILE convert local pet file to a tar.gz package
pet2txz PETFILE convert local pet file to a tar.xz package
sfs2pet SFSFILE convert local sfs file to a pet package
tgz2pet TARFILE convert local tar.gz|tgz file to PET
txz2pet TXZFILE convert local tar.xz|txz file to PET

workdir set a new working directory. Default is ~/pkg/
autoclean auto delete pkg files after download+install

show-config show current config, repo and search settings
func-list list all functions used in this program
welcome print some useful cmds to help get started
version|v show the version of this script

examples|ex show example command line usage of pkg
usage [CMD] show usage of CMD, or list available cmds
help|h show this help information
help-all|H show a full description, with added info

Known Issues

* dependency resolution can be slow

* No good preview of file sizes given before install

* Pkgdialog needs a re-write in places to make it faster after you chose multiple packages to install/remove/update/etc.

This might be useful to you if:
- you want an easy way to manage packages without X
- you want to programatically manage packages (write your own package installers/removers, etc)
- you want to remotely remaster/customise an ISO or SFS without booting it or manually hacking at the filesystem
- you want to make build script and easily compile re-producible PETs.
- you want to use SSH, Vagrant or similar to auto build a custom Puppy.
- you'd rather use a command line package manager than PetGet

** How is this different from PetGet?

- PetGet is a little faster and more reliable.
- PetGet can do things Pkg cant and vice versa.
- Pkg uses PetGet to update the repo files
- Pkg can compile packages from source, PetGet can't
- Pkg can convert PET to SFS, DEB to PET, etc
- Pkg can be used in your own scripts to automate stuff
- Pkg provides many ways of examining packages that PetGet doesn't
- PetGet basically doesn't work without X, except some very basic stuff
- Pkg has 3 GUIs, all of them are worse than PetGet
- It's easier to add new repos using Pkg

** Why won't TAB complete work for packages X, Y and Z?

Maybe the packages aren't in the current repo. Switch repo, or run `pkg which-repo <pkg-name>` to find out which repo the pkg is from.
Or, try running `pkg repo-pkg-scope all`. This will slow down TAB autocomplete, but will include all repos by default. To reset, do `pkg repo-pkg-scope one`.

** Do I have to type all those commands?

Not really. There are THREE different frontend UIs for Pkg. Type any of the following in the console to use them instead:

Code:

pkgdialog

- ncurses dialog based frontend, works without X

Code:

Xpkgdialog

- Xdialog based frontend, requires X

Code:

Gpkgdialog

- GtkDialog based frontend, requires X

** Why can't I build packages?

You need the devx installed, and Pkg will auto-install petbuild for you.

Inside the RC file (/root/.pkg/pkgrc), you can change the BUILDTOOL variable:

Change BUILDTOOL to 'buildpet' to use that tool instead (it's very similar to petbuild, but older).
Change BUILDTOOL to 'sbopkg' to use that tool instead (sboPkg must be installed).
Change BUILDTOOL to 'src2pkg' to use that tool instead (src2pkg must be installed)._________________Pkg, mdsh, Woofy, Akita Linux, VLC-GTKLast edited by sc0ttman on Sun 25 Mar 2018, 14:58; edited 8 times in total

- Name: the name of the repo.
- PkgExt: the file extension of the packages in the repo.
- RepoFile: the repo database file, must be in /root/.packages/[your-repo-file]
- URL1-4: the repo URLs, only URL1 is required.
- FallbackList: the order in which other repos are to be searched.

Oh wow, this is so awesome Scott! Nice work man. I was just looking to install pkg for the features I've grown accustom to like installing from the command line or forcing a pet to install, but I see you've added a bunch of new awesome features too!

You can now copy and paste commands from Ubuntu and Debian forums and many websites, to easily install packages and follow the commands..

Further improvements:

1. Support the following command in an add-apt-repository wrapper:

Code:

add-apt-repository ppa:[USERNAME]/[REPOSITORY NAME]

This would make it possible to convert the huge number of PPA repos available online into Pkg (and Puppy) compatible repos...

Then we could add those repos as usual, with `pkg --add-source <repo-db-entry>` (or whatever apt-* commands we can fake)

2. Use `pkg --ask` by default, and remove --ask if the -y option was given to the apt wrappers_________________Pkg, mdsh, Woofy, Akita Linux, VLC-GTKLast edited by sc0ttman on Sun 01 Apr 2018, 07:15; edited 1 time in total

The apt and yum lookalike-frontends look great sc0ttman. Commandline package manager facilities like this is what will keep Puppy alive for many years to come (I'd say it is essential). Woof-CE itself is basically, currently, a build system whose useful purpose, it seems to me, is to provide a basic 'recipe' so that when new version of say Debian, or Ubuntu, or Slackware come around, it is much less work than the old days, for a developer to build a new Puppy iso (since just copy old recipe and tweak it a bit as required for new version). Once the new iso is produced, however, for the new flavour, personally I feel that (in current form) woof-CE has done its bit and tinkering with the new iso is a matter of re-mastering to produce 'flavours', which is the same as it always was.

I've been recently asked to add features to my makepup script (basically to make it more like mklive-Stretch of DDogs, but truth is debootstrap from Debian is a commandline build system, which woof-CE isn't, so the purpose is different and the frontend is for that different purpose.

It would be nice to see a new Puppy build system that works like debootstrap - then it would be easy for anyone to design/make/build their own isos with whatever desktop environments they want - but I really don't see the current woof-CE as being that kind of build system - it is for new one of creations and remastering is then expected in order to modify the new Puppy. Truth is, only one published iso is sufficient - then people can remaster after that. However, a powerful package manager, such as yours is the key to easy and reliable modification prior to remastering; having said that, it could I suppose be built into woof-CE build stages (allowing the mods to be made as part of woof-CE iso creation - then woof-CE would become more flexible and powerful, and then makepup could have buttons etc added to benefit from that addition.

So even if woof-CE is never re-written to become like a debootstrap for Puppy, the current one-off woof-CE build script system could become very powerful should it have a reliable dependency-resolving package manager built in for last stages of its iso production. Hoping that will happen one day, and I'd mod makepup to use such new facilities (or some other frontend could be supplied in woof-CE itself, which would be a better approach really, since easier to maintain and easier to code since woof-CE could be purposely made to work with it)..

Keep up the good work and I hope you are dabbling into woof-CE itself to see if you can integrate your package manager capabilities directly in there too.

the PPM appends installed packages to the end of /root/.packages/user-installed-packages where as pkg sorts 'user-installed-packages' into alphabetical order. Appending makes it easier to uninstall a group of packages & deps you don't want, as they will be grouped together in the list.

pkg contains it's own 'postinstall_hacks' where as it might be better to call the one in /usr/local/petget as some of the fixes are distro dependent

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum