Better command line tools, and pkg manager suggestions

[sc0ttman]

I have (lots of) suggestions for future Puppy releases.

My Suggestions, in short:

- build good command line apps, and then make separate (gtkdialog) GUIs for them
- Puppy needs a command line package manager (like mine, but better...see latest posts in thread for downloads)

- Puppy needs a fancy, web-based repo/pkg browser (local or online) .. (like salix pkg search, alpine pkg search, or tinycore pkg search)
- Puppy needs a public website for building custom Puppy ISOs
- Puppy needs contrib repos for each official release


Please post YOUR suggestions to this thread about:

1. Improving command line tools in puppy:

- what CLI cmds are missing in Puppy that you like? .. convert? locate?
- what CLI cmds are pain (or scary) to use? .. i hate fdisk..
- what CLI cmds should *Puppy* have? .. pupinstall (like Universal Installer, but no gui), adblocker (like Pup-Advert-Blocker, but no gui), etc

- candidates for "separation of GUI and CLI", such as: Peasywifi, pup-advert-blocker, puppyinstaller, sns, others?
- de-coupling puppy apps from X
- how to improve command line option handling (links to good recipes, ideas, snippets, etc)

- what you want from a CLI package manager
- how to improve error code handling (links to good shell tutorials)
- how to go about making a web-based package manager frontend
- how to best fork and edit the Salix package search site, then where to host

- desired features/workflow/options for Pkg
- suggest command/features you like in other pkg managers that you want in puppy
- etc

2. Suggest command/features you like in other pkg managers that you want in puppy

- what you want from a CLI package manager
- desired features/workflow/options for Pkg

3. Suggestions for a localhost, PHP/PERL web-based frontend for Pkg

- how to go about making a web-based package manager frontend

4. Suggestions for a 'Puppy Linux Package Search' website

- how to best fork and edit the Salix package search site, then where to host


More info:

A command line package manager is not available in Puppy.
PetGet can do only the very, very basics without loading up GtkDialog.

In fact, no apps should need gtkdialog, or even X .. Only their frontends should

NOT building separate UIs and backends is a bad habit of many devs and users (myself included)!

EDIT : AntiX has this: https://github.com/BitJam/cli-shell-utils

Integrated utilities for CLI programs (that can be called from GUIs)

A small gtkdialog GUI (like Pup-Advert-Blocker) has the following requirements:

- boot all the way to desktop
- get a WM with menus.. or get a terminal emulator
- find and use a separate GUI to configure net connection, if needed
- find Pup-Advert-Blocker, load it up
- read it, click the right buttons
- ...now finally it runs .. phew!

To prove the point, In the Advert-Blocker thread, technosaurus posted a little bash script to do the same ad-blocking automatically..
His script could be added to startup even before X is trying to load..

EDIT: In fact, it someone DID re-use the command line version and cut out the GUI stuff (for their own): https://github.com/antiX-Linux/advert-block-antix

Another example: Deluge BitTorrent client, in 'ThinClient' mode, separates its daemon (backend),
and offers 3 different UIs to interact with it... You can manage your torrent from command line,
web browser, GTK interface, or just leave the daemon running in the background...

https://askubuntu.com/a/65406

1. Separating a program into CLI and GUI components have has benefits:

* can have a user-friendly, simple, painless setup and install without X
* Puppy users would get lots of unique, user-friendly command line tools
* these puppy-only CLI tools would make no X setup much less painful on old hardware
* users like radky, zigbert and others would have lots of great tools to build GUIs for!

* can use a program without X and its many deps
* can have multiple frontends and GUIs for the program
* can easily create simple-to-use wrappers for more advanced/complex command line tools
* command line tools can work over ssh, in chroots, fake roots, etc
* command line tools are more portable, often requiring no binary deps
* command line tools are scriptable, GUIs are (usually) not


Having lots of good command line tools also means you can provide other users with better documentation,
with well commented, reproducible, copy-and-paste code examples for common tasks..

2. Having a CLI package manager would have these benefits:

* can add/remove pkgs from a remote system (using ssh, or a chroot)
* easier to build/compile pkgs on a remote system
* can update the PPM features without breaking the GUI(s)
* puppy could more easily be used with Vagrant, Docker, etc
* could even have a fully featured pkg manager in the initrd, for some reason..
* programmable in other scripts: other scripts can call the package manager, even in the background to easily setup stuff.

So, for example, I made a command line package manager called Pkg-1.9.0alpha-noarch which has 3 different interfaces:

- the command line interface, with context-sensitive TAB completion of options, pkgs name, repos, etc
- a ncurses/dialog based frontend called Pkgdialog (similar to the Pkgtool and Sbopkg interfaces)
- a GTK interface (using gtkdialog) similar to PetGet

3. Puppy needs a *collection* of various package manager frontends:

* a dialog frontend for easy menu-based package management without X
* a gtkdialog frontend for an easy, gtk based GUI in X
* a command line PHP or CGI (PERL) interface (using query strings, a wrapper for the real command-line pkg manager)
* an HTML4/CSS2/JS web frontend for the PHP/CGI backend
* the package manager web frontend(s) could be accessible over localhost

4. Puppy could have a public website for building (remastering) custom Puppy ISOs

* needs the site hosted at ibiblio, with all the official release ISOs
* needs a PHP powered web server
* web server needs some scripts available to unpack ISO, unpack SFS, chroot into SFS, update pkg selection, [replace kernel and boot manager], rebuild SFS, rebuild ISO
* a command line pkg manager (installer/remover) of some kind would be needed for this to work

5. Puppy users need an easier way to share PETs and packages they make or compile.

* contributing .petbuilds scripts is the besy way to go
* creating a contrib repo is also a good idea
* currently other users would have to hack various files in /etc and ~/.packages to add another users contrib repo
* Puppy users need an easier way of creating their own contrib repos
* Puppy users need an easier way of sharing, adding and removing other users contrib repos to their system

[sc0ttman]

About command line package managers:

I created Pkg 1.9.0alpha:
- currently only ~120kb,
- only deps are busybox, coreutils
- shell only, uses busybox ash (no bash needed), no binaries
- supports .deb/ubuntu pkgs, .PETs, arch pkgs, slackware pkgs, .rpm,
- includes buildpet, but will get and use 01mickos petbuild by default
- (so Buildpet can probably be removed from Pkg)
- change buildtool backend in ~/.pkg/pkgrc, See BUILDTOOL=
- Valid options are petbuild|buildpet|sbopkg|src2pkg.
- Pkg has so far been tested on Slacko-6.9.9.9 and X-Tahr-*.*

To give suggestions on improving Pkg, or Puppy packaging generally, please post here for now.

Note to self:

It would be a good idea to steal ideas and code from

- pkgtool - http://www.slackware.com/config/packages.php (OFFICIAL slackware pkg tools [makepkg, installpkg, removepkg, explodepkg, rpm2targz], also with ncurses/dialog frontend)
- slpkg - https://github.com/dslackw/slpkg (a Slackware pkg manager)
- spkg - https://github.com/megous/spkg (another unofficial Slackware package manager, for installing unofficial/non-repo packages )
- slakpkg https://slackpkg.org/ (another slak pkg manager, frontend for pkgtools, includes ncurses interface)
- slkbuild - http://slkbuild.sourceforge.net/ (builds from sboPkgs, for Salix)
- slapt-get - http://software.jaos.org/#slapt-get (apt-like pkg tools for Slackware)
- gslapt - http://software.jaos.org/#gslapt (GTK frontend for slapt-get)
- slapt-src - http://software.jaos.org/#slapt-src (like slapt-get, for compiling pkgs from build scripts)
- Sourcery - https://docs.salixos.org/wiki/Sourcery (GTK frontend for slapt-src)
- src2pkg - http://distro.ibiblio.org/amigolinux/download/src2pkg/ (the daddy)
- sboui - https://github.com/montagdude/sboui (ncurses frontend for Sbopkg and sbotools.. fast, in C.. good docs on making a compatible pkg manager backend)
- sbotools https://pink-mist.github.io/sbotools/ (a ports-like interface to SlackBuilds.org, in PERL, makes much easier to compile 32bit on x86_64 etc)
- sbobuild - https://github.com/gapan/sbobuild (builds pkgs from slackbuilds.org, for Salix)
- slint-scipts - https://github.com/djemos/slint-scripts (a collection of scripts for Slackware Live [making live ISOs])
- SBuilder - https://linuxoutpost.com/SBuilder/tutor ... ge_manager (builds slackware ISOs, injects its own pkg manager)
- repo-scripts - https://github.com/gapan/repo-scripts (used to maintain the Salix repos)
- salixtools - https://github.com/gapan/salixtools (ncurses salix system utlities, includes a repo sources updater)
- slackrepo - https://github.com/idlemoor/slackrepo (Slackware tool for making and managing repos, by building from repos of SlackBuilds)
- fatdogs pkgtools - url ??? (Slacware compatible, but faster)
- other stuff? DebianDog build tools, etc? Link to them here..

Most of the above would be better than my own ...
But mine does already support native Puppy repo files, DISTRO_SPECS, the stuff in ~/.packages/*, etc

General observation: the huge array of packing tools, options, UIs, workflows, and therefore AVAILABLE PACKAGES in Slackware is
(partly) because Slackware (like CRUX) has good, simple command-line packaging/compiling commands at its heart,
which users can build on top of...

Source code for Salix package search website (which is very fancy): https://github.com/gapan/packages.salixos.org ...
Puppy could have something similar if we forked it and gave it a home online..

See also:

http://guide.salixos.org/31PackageManagement.html
https://docs.salixos.org/wiki/Using_Sal ... ld_scripts
https://docs.salixos.org/wiki/Building_ ... h_slkbuild
http://guide.salixos.org/32Packagemanag ... e.html#4_2
http://www.slackbook.org/html/package-management.html
https://mgalgs.github.io/2011/12/08/cre ... -hand.html

[wiak]

The Suggestions, in short:

A command line package manager is not available in Puppy.

PetGet can do only the very, very basics without loading up GtkDialog.

In fact, no apps should need gtkdialog, or even X .. Only their frontends should.

This is correct, sc0ttman. We badly need a good commandline usable package manager for Puppy and been a bad habit to build gtkdialog apps rather than commandline apps with gui frontend options.

The last thing developers should consider is the gui, but alas I think they are tempted to make a gui straight away because it appears glamorous and attractive to users. Too much in a hurry to attract attention, creating quick-fits, rather than trying to build quality into their apps. Fact is, the gui can't be designed properly till all the commandline options are worked out and stable - hence gtkdialog/gui-prioritised apps tend to be no use or of limited use for commandline-based work, since that was never developed/incorporated into the design.

Behind the scenes, it is the commandline (including shell and the many related utilities) that make Linux powerful (via file descriptor redirection, and pipes and other message-passing mechanisms). The Pelo-termed 'passengers' don't care about commandline, and don't want technical development 'talk' but then they would end up with no development and no Puppy. User-friendly interfaces don't come from chatter, they come from careful and intensive development and testing. There are so many quite nice Puppy apps/utilities that would have been so much better if attention had been given to proper commandline optional operation.

wiak

[wiak]

I'm looking forwards to your first release, because I'm needing something like this to be available.

wiak

[sc0ttman]

I'm looking forwards to your first release, because I'm needing something like this to be available.

wiak

Yeah, I'm looking into making Pkg and Woof play nice so that you can easily pkg --remaster, or better yet pkg --rebuild (uses Woof to rebuild-current-puppy-from-scratch), all from the command line, with a few easy commands... Or something

I once made something called Woofy .. You might have seen it..

But if not, Woofy is here: http://www.murga-linux.com/puppy/viewtopic.php?t=57037

But yet again, it's not CLI + frontend.. Stupidly, I made it a gtkdialog GUI only ..

However, iguleder (brilliantly for me) was way ahead of me at every step..
Check his code in the woofy thread for a CLI rebuild-puppy-iso tool..

My woofy code is crap, and prob no longer works without a few tweaks (check the terminal output) but it might give you some ideas..

[wiak]

I'm looking forwards to your first release, because I'm needing something like this to be available.

wiak

Yeah, I'm looking into making Pkg and Woof play nice so that you can easily pkg --remaster, or better yet pkg --rebuild (uses Woof to rebuild-current-puppy-from-scratch), all from the command line, with a few easy commands... Or something

Yes, that's exactly the need I'm talking about. I've heard of Woofy I think. I used Akita for a bit so maybe it was back then?

wiak

[sc0ttman]

Just for testing, and to 'suggest' what a CLI package manager in Puppy might be like,
here is my Pkg Manager (pkg-1.9.0alpha-noarch.pet, see below)

INSTALL:

Install the PET using PetGet, as usual.

SETUP:

Run pkg once then update your bash profile, setup your repos:

Code: Select all

pkg -h    # just to setup some stuff
. /etc/bash_completion.d/pkg        # enables TAB auto completion
pkg --update-sources                    # builds list of available repos

That will enable TAB completion of pkg names etc in your terminal,
then update the list of repos available on your system

Any other help, look in /usr/share/doc/pkg/

Or do `man pkg` .. if you have the real 'man' installed and MANPATH=/usr/share/doc:$MANPATH

EDITING:

/usr/sbin/pkg <-- the pkg manager
/usr/sbin/pkgdialog <-- ncurses frontend
/usr/sbin/gpkgdialog <- gtkdialog frontend

/usr/sbin/pkg is a big file, I STRONGLY recommend doing "Fold All" in Geany..
It will be much nicer to read, edit, etc..

TECH NOTES

- Pkg has its own versions of dir2pet, tgz2pet, pet2tgz, etc, etc as internal funcs.. They are based on the latest Woof-CE versions..
- Pkg includes some other scripts for SFS installing without X, based on older sfs_loader stuff.. They may no longer be needed..
- Pkg expects packages (PETs, .txz files, etc) to be in its WORKDIR (~/pkg), it will move pkgs there every time.
- Packages you build, convert or combine (pkg + deps) will go into its WORKDIR as well.
- Use `pkg --workdir /path/to/dir` to move the WORKDIR somewhere else
- Package includes a modified version of buildpet (by Tman/iguleder)..
- If BUILDTOOL in pkgrc is NOT buildpet, you can remove /usr/share/buildpet/* and /usr/sbin/{buildpet,splitpkg}
- some pre--woof stuff is left in Pkg (mostly about alienpackages.txt).. I don't intend to keep it, pre-woof stuff can be removed..

LIMITATIONS

1. Not good at working with local files

Pkg moves all pkgs into ~/pkg (WORKDIR) before working on them .. Pkg dies all it's work from there..
This becomes annoying when working with local files.. I am gonna fix this.

Local pkgs/files (or their converted/combined output files) should not be moved to WORKDIR,
they should end up in the same dir they started.. Much less annoying.

Only repo pkgs should need a default location to live.. WORKDIR is it..

2. No conflict resolution

Pkg doesn't do much/any conflict resolution .. Not sure what PetGet does, but Pkg
will not refuse to replace existing files, although this could easily be done in Pkg, by
adding some new code in the install() func that makes used of --contents and --which

Pkg could do something like this (screenshot of CRUX linux pkg-add docs):


3. Simplistic install method

Large parts of the install() func were stolen from PetGet..

Therefore, Pkg has 1 install method - copying stuff to / ... I dunno what PetGet does for each PUPMODE.
The src2pkg program by amigo has many install methods, so a good place to look for more clever approaches..

TO DO

- FIX on lots of pups .. Debian based .. Ubuntu based .. Slack based..
- FIX: Lots of refactoring to do .. Lots of sed piping to sed ... etc .. DONE
- FIX: speed up => Pkg often calls itself like so `$0 --opts BLAH`, call the internal funcs instead.. DONE
- FIX: better TAB completion for local files and dirs ... DONE
- FIX: Lots of repetitive code could be refactored into funcs ..
- FIX: maybe some excessive/needless quoting and escaping of stuff

Mostly tested on a recent Slacko 32-bit...
Only much older versions were tested on anything else (Akita, X-Tahr)..

Never tested on x64 or ARM...

MANAGING REPOS

Look in ~/.pkg/pkgrc for current repo and current repo info & settings
Look in ~/.pkg/sources-all for all supported repos
Look in ~/.pkg/sources for all repos actually in use

Check commands --repo, --repo-list, --update-sources, --show-config

BUGS

pkg --get-only PKGNAME : doesnt work ...
The --get-only option should get (download) the PKG and all deps, but not install them.. It is not getting the deps..

--repo-pkg-scope : not being respected (I think)...
Basically, --get should not install pkgs from other repos unless --repo-pkg-scope is 'all' (in ~/pkg/.pkgrc)
Note, pkg *should* install deps of pkg from any repo by default, Set --repo-dep-scope all|one to choose..

pkg --contents PKGNAME : does not always list file contents in the same format

It depends where it got the list (archive file, pkg file, ~/.packages/PKGNAME.files, ~/.packages/builtin_files/PKGNAME, etc)..
Sometimes the list includes the pkg name, sometimes just a leading slash, sometimes no leading slash!
I would love to fix this and make --contents always output full paths with leading slash, no leading pkg name.

I'm sure you will find many more!

MY ROADMAP FOR PKG:
- first class support for all Puppies built by woof
- very good support for compiling from build scripts
- good tools included for creating .petbuilds from: Pkgfiles, SlackBuilds, SlkBuilds, Apkgfiles
- support x86, x64, ARM puppies and fatdog
- keep using ash, not bash (or as fast and portable as possible anyway)
- keep it all in one file
- keep it all in funcs, if poss
- make it faster
- make the code cleaner
- reduce the amount of code
- dont increase deps, reduce them if poss
- reduce capitalisation of vars (except PKG* and ENV vars)
- improve comments

SUGGESTIONS: (if you like them, tell me, I will try to add them)

- I'd personally like an easy way to submit *.petbuilds to puppylinux-woof-CE/petbuilds, via some testing branch ..
Then devs could pull them down, using petbuild to build them, test the builds,
and finally merge the new petbuild into the real branch if its good..

- I'd maybe like pkg --dir2pet, --pkg-build (and others) to have their own options, examples:

pkg --dirpet vlc-2.3-i486 --cat "Multimedia" --deps "+qt,+libblueray"

Would that be useful to anyone?

- I'd like to add a `pkg --grep [OPTS] 'search' "PKG1 PKG2"` option, for grepping pkg info
like (name, cat, deps, size, repo, etc), plus pkg contents and build script (compile options) info, all in one.
.. anyone who could hack Pkg to do this would be awesome..

- I will add capitalized versions of some of the short options (-c, -li), which will return more verbose
output than their lower case equivalents.
Example: `pkg -C PKG` will list package contents, just like -c, but also showing files sizes:

Code: Select all

/usr/bin/vlc    349k
usr/share/applications/vlc.desktop    1k
...etc...

Maybe add these options:

pkg --explode PKGNAME # unpack/extract pkg into './pkgname/', but don't install or run any scripts in the pkg

pkg --blacklist PKGNAME
from slakpkg - "With this command, you could"blacklist" certain packages. Packages blacklisted can't be installed, upgraded,
or removed using the slackpkg utility. If you want to remove some package from the blacklist,
you will need to edit /etc/slackpkg/blacklist."

More possible future ideas (may require petbuild updates):

1. When petbuild is the backend (see BUILDTOOL in ~/pkg/pkgrc):

- custom build and configure opts:

pkg --pkg-build --CFLAGS='-blah -more' --configure='--disable-nls --disable-x11' PKGNAME

2. When src2pkg is the backend (see BUILDTOOL= in ~/pkg/pkgrc)::

pkg --pkg-build [src2pkg options] FILE|URL

3. For src2pkg, petbuild, sbopkg, CRUX port tools to all play nicer together as source-to-package backends for Pkg...

4. More portable/familar setup, env vars, etc

DISTDIR="~/.packages" # should really be /etc/packages or /etc/sources
PKGDIR="~/pkgs" # or wherever the user wants to keep downloaded pkgs

5. Steal this from Salix (spi): simulate pkg action, rather than actually do it
- `spi --simulate -i packagename # simulates installation`

6. Do a Pkg option: `pkg --dir2deb `
- See https://gist.github.com/elwinar/c8658987699e62ee201b

Helping me out (if u like):

Any changes, fixes etc you want (need!) to make, please post them to this thread for now...
Eventually this PET will live in Woof, as a package available in the 'noarch' repo (I hope)..

Once this has been improved enough, I will try to get it into Woof-CE, then any more work on it have to be done inside Woof-CE..

Please add a comment explaining your changes, with ", YOURNAME" at the end, like so:

Code: Select all

# use sed only to remove blah and blah, pupuser234

Note to self, figosdev might be interested.... https://www.tapatalk.com/groups/antix/d ... t7047.html

Cheers, hope you like it.. (hope it works!),

Cheers,
Scott.

[sc0ttman]

So I am looking for Suggestions on the following:


User contrib repos:
- each user can build a Packages-puppy-slacko14.2-contrib-$user repo file
- upload repo file to ftp://**.org/puppy-contrib/slacko14.2-contrib-$user/$repofile
- pkgs would live in the same dir as the repo file: slacko14.2-contrib-$user/[pkgs here]
- each user can maintain their own contrib repo
- User must add their FTP login details to Pkg rc file
- Pkg can then upload their built packages to their contrib repo

End-users could then add as many contrib repos as they like,
knowing there is "no warranty" for that repo,
but over time, users would learn who hosting good/up-to-date pkgs, etc
.. Just like CRUX, Deb, Ubu, etc...

Pkg maintainers could host repos just for their packages,
or users could have a contrib repo for all the extra packages they compiled, etc..

Maybe something like this:

mysite.org/puppy-contrib/slacko14.2-$arch-contrib-xfce4
mysite.org/puppy-contrib/slacko14.2-$arch-contrib-radky
..etc...

Best web-based interface (localhost)
- PHP or PERL backend? cgi is more portable I guess.. fewer deps..
- i know PHP but can only hack existing PERL

Best online package search n download site:
- which frontend to use? .. Salix package search is lovely, could be forked..?
- where to host it? would prob need webserver with php, cgi, .. that's it..

Best online "build your own ISO" site:
- please post links to any you know of (the best ones)
- what would a puppy "build your own ISO site" need?
- the webserver hosting the site would need to have lots of ISOs and their repos installed on same server...
- anything else meeded on the server, other than the site itself, some shell scripts and some PHP exec calls?
- where would be the best place to host it? Ibiblio I guess, it has all the official releases (ISO files) and their supported repos in one place already!


Source to pkg compiling tools:
- the best BUILDTOOL backend (I vote petbuild, cos it's part of woof-CE)
- other build tool backends to support if available (like sbopkg, see my list above)

EDIT:

Improving petbuild (much of this might already work .. not yet sure)
- add a script like /usr/sbin/petbuild_installer to devx, that downloads (clones) the .petbuilds scripts to /usr/share/petbuilds/
- move all petbuild configs to /etc/petbuild/
- make all build vars (CFLAGS, ./configure opts, etc) in /etc/petbuild/build.conf and *.petbuild overwritable by setting ENV vars before build
- an optional MAKEDEPENDS field in .petbuilds, so user know which extra build tools/libs are 'needed at compile time, but not run-time'
- an optional OPTDEPENDS field in .petbuilds, so users know which deps provide extra features
- an optional PREREQS field in .petbuild scripts, listing the built-in pkgs that are needed:

Since a normal SBo SlackBuild's .info file specifies packages required for building with the assumption of running on a fully installed Slackware system and because we run spbuilder in only a minimal installation, we extend .info files with an additional PREREQS field to specify the need for any stock Slackware packages not already available in the minimal system.

- an optional RECOMNDS field in .petbuilds, for edge cases, certain archs, etc.. could differ depending on which branch of petbuilds you are in

With some nice *DEPENDS or PREREQS fields listing the (different kind of) dependencies each source package needs in order
to be built, packaged, then run successfully, it shouldn't be too hard to automake petbuild build queues of packages, and
have them all compile in one go, in the right order.

(I'm no petbuild expert, muc hof the above may be implemented already, or simply
not be a good suggestion)

[musher0]

Hi scotman.

I just downloaded your alpha.

I'll try to figure out how it works.

My point of view may be biased, though, in the sense that PPM stops
working after a while on Frenchified Puppies. And I'm looking for a solution
to that.

I've posted the problem a couple of times on the general forum, and the
only answer I got was "use PPM with a pristine Puppy." Which does solve
the problem, but is a practical complication. reboot on a fresh Puppy, only
download your thing, reboot in your current Puppy, and finally install the
thing.

So hopefully your script(s?) will cut through the language barrier -- or
whatever it is that is hampering the PPM in some situations.

So thanks for being the somebody somewhere paying attention.

TWYL. BFN.

[musher0]

Hello again, scotman.

Typo: you left a "function" at line 540 or thereabouts in the < pkg >
script....

Code: Select all

validate_url () {
	# there was a superfluous "function" word here!
	if [[ `wget -S --spider $1 2>&1 | grep 'HTTP/1.1 200 OK'` ]]; then
		echo "true"
	else
		wget -S --spider $1
	fi
}

~~~~~~~~~~~~~~

Ok fine. I have the opening blurb. What do I do next?!

TIA.

[sc0ttman]

Ok fine. I have the opening blurb. What do I do next?!

TIA.

press up, down, page up, page down, space, or q ... it is the help piped to less/more .. You must have called pkg with no options, which defaults to pkg -H..

I can remove less/more from pkg -H if its annoying or unfamiliar to people..

Anyway, I will condense the above setup into this quick start guide:

Code: Select all

# after installing Pkg run these commands:
pkg -h
source ~/.bashrc
pkg --update-sources

That should set you up...

Then you can start using Pkg:

Code: Select all

# see the available repos
pkg --repo-list

# change repo
pkg --repo NAME

# search the current repo (use TAB to complete pkg names)
pkg -n PKGNAME

# download a pkg (use TAB to complete pkg names)
pkg -d PKGNAME

# get (download and install) pkg, and all its deps
pkg -g PKGNAME

etc

EDIT... I guess Pkg should run --update-sources itself on first run that would make sense..

[musher0]

Many thanks.

NO-no-no! Please do not change from using the less utility, it's great that
you thought of using less to present the basic info. (I'm a great less fan as
you may [not] know.)

What I will do, though, because there is no way I'll remember all those
options by heart, is start < pkg > like so:

Code: Select all

nohup urxvt -g 82x28+40+40 -title "ScotMan's Pkg Utility" -fn xft:Monaco:pixelsize=15 -e pkg &

Then I have your help reference in one corner, and I still have the
originating console to use the actual commands.

I don't want to put my head on the log just yet, but I suspect that you've
come up with the kind of utility a lot of Puppyists have been waiting for...

TWYL.

[musher0]

BTW, why would you have to source ~/.bashrc?
Bash does it automatically when the Puppy session starts, no?

BFN.

[musher0]

Hello again.

I wish to be able to access the repos DPupStretch-7_fr is not
accessing anymore through PPM. They are as follows (in file
/root/.packages/DISTRO_COMPAT_REPOS):

#
# DISTRO_COMPAT_REPOS
#

if [ "$DISTRO_COMPAT_VERSION" = "" ] ; then
[ -f ./DISTRO_SPECS ] && . ./DISTRO_SPECS
fi

case "$DISTRO_TARGETARCH" in
x86) DBIN_ARCH=i386 ;;
x86_64) DBIN_ARCH=amd64 ;;
esac

case $DISTRO_COMPAT_VERSION in
wheezy) DDB_COMP=bz2 ;; #older versions
*) DDB_COMP=xz ;;
esac


#----------------------
#PKG_DOCS_DISTRO_COMPAT - where to download the compat-distro pkgs databases from
#---------------------
# 1|2|3
# 1 - domain. for testing the url.
# 2 - full URI of the database file.
# 3 - name of db file when local and after being processed into standard format

PKG_DOCS_DISTRO_COMPAT="
z|http://http.us.debian.org/debian/dists/ ... SION}-main
z|http://http.us.debian.org/debian/dists/ ... }-non-free
z|http://http.us.debian.org/debian/dists/ ... N}-contrib
z|http://deb-multimedia.org/dists/${DISTR ... multimedia
"

#-------------------
#REPOS_DISTRO_COMPAT - hardcode the compat-distro repos in here...
#-------------------
# 1|2|3
# 1 - domain. for testing the url.
# 2 - full URI of the repo
# 3 - name of db-file(s) associated with that repo. it may have glob wildcards.

REPOS_DISTRO_COMPAT="
z|http://http.us.debian.org/debian|Packag ... _VERSION}-*
z|http://deb-multimedia.org|Packages-debian-${DISTRO_COMPAT_VERSION}-multimedia
z|http://mirrors.kernel.org/debian|Packag ... _VERSION}-*
z|http://ftp.de.debian.org/debian|Package ... _VERSION}-*
"

#---------------
# fix variables
#---------------
PKG_DOCS_DISTRO_COMPAT="$(echo "$PKG_DOCS_DISTRO_COMPAT" | sed '/^$/d' | tr '\n' ' ' | sed 's% $%%')"
REPOS_DISTRO_COMPAT="$(echo "$REPOS_DISTRO_COMPAT" | sed '/^$/d' | tr '\n' ' ' | sed 's% $%%')"

How do I do that? How do I add these Debian repos to the ones
you give as example?

TIA.

[sc0ttman]

BTW, why would you have to source ~/.bashrc?
Bash does it automatically when the Puppy session starts, no?

BFN.

Not for me on Slacko.. Maybe a fix is needed in Pkg..

But I must run

Code: Select all

. /etc/bash_completion.d/pkg

before I get TAB completion..

Pkg adds this to ~/.bashrc (if not already there) on first run, so that's why I sourced it ...
You're right, though.. I should just source /etc/bash_completion.d/pkg instead ..

How do I add these Debian repos to the ones you give as example?

Type the following, hit ENTER and follow the instructions:

Code: Select all

pkg --add-source

ADDING REPOS MANUALLY:

The file /etc/sources-all contains all repos that Pkg will support.

It has entries in this format:

Code: Select all

#repo_name|pkg_ext|repo_file|mirror1|mirror2|mirror3|mirror4|fallbacks

mirror1 is required, others are optional (can be empty).. these are the urls of the repo dir containing the pkgs or subdirs..

So, add *something like* the following entries to /etc/sources-all:

Code: Select all

DPupStretch-7_fr|pet|name-of-repo-file|url1/|url2/|url3/|url4/|name of repos in order to fallback to

Then run:

Code: Select all

pkg --update-sources

EDIT:

Though you will hit troubles. I've never seen a ~/.packages/DISTRO_COMPAT_REPOS file that contained this:

Code: Select all

case $DISTRO_COMPAT_VERSION in
wheezy) DDB_COMP=bz2 ;; #older versions
*) DDB_COMP=xz ;;
esac 

That code will need to be added to Pkg, near the top.. Around line 103, under the similar DISTRO_TARGETARCH stuff..

[sc0ttman]

there is no way I'll remember all those options by heart

Hopefully you won't have to ..

The options are designed to match the words/sounds you'd use to tell pkg what to do..
The idea is you should be able to eventually predict what the options are going to be:

Tell pkg to do a package build:

Code: Select all

pkg -pb vlc

Show pkg contents of vlc:

Code: Select all

pkg -c vlc

Tell pkg to get deps of vlc:

Code: Select all

pkg -e vlc

Tell pkg to list the deps of vlc:

Code: Select all

pkg -le vlc

Tell pkg to create sfs with combined VLC and deps:

Code: Select all

pkg -sc vlc

And many other options should be familiar:

--dir2pet, --dir2sfs, etc

Also, pkg will auto-complete options:

Code: Select all

# pkg --deps[TAB TAB]
--deps           --deps-all       --deps-check     --deps-download

Code: Select all

# pkg --[TAB TAB]
--add-source           --help                 --repo
--all                  --help-all             --repo-convert
--all-pkg              --install              --repo-dep-scope
--ask                  --install-all          --repo-file-list
--bleeding-edge        --list-deps            --repo-info
--contents             --list-downloaded      --repo-list
--deb2pet              --list-installed       --repo-pkg-scope
--delete               --names                --repo-update
--delete-all           --names-all            --search
--deps                 --names-exact          --search-all
--deps-all             --names-exact-all      --sfs2pet
--deps-check           --pet2sfs              --sfs-combine
--deps-download        --pet2tgz              --show-config
--dir2pet              --pkg-build            --tgz2pet
--dir2sfs              --pkg-build-list       --txz2pet
--dir2tgz              --pkg-combine          --uninstall
--download             --pkg-installed        --uninstall-all
--examples             --pkg-repack           --update-sources
--force                --pkg-status           --version
--get                  --pkg-update           --which
--get-only             --recursive-dep-check  --workdir

All short options are the first letters of each word:

Code: Select all

--pkg-build    -> -pb
--pkg-combine    -> -pc
--get-only    -> -go

More examples:

Code: Select all

 pkg -u "PKG1 PKG2"		uninstall multiple packages from the system
 pkg -d "PKG1 PKG2"		download multiple packages from the repo
 pkg -pb "PKG1 PKG2"		compile, build & install multiple pkgs
 pkg -li "PKG1 PKG2"		list installed pkgs matching PKG1 or PKG2
 pkg -s SEARCH			list pkgs in current repo matching SEARCH
 pkg -sa SEARCH			list pkgs in all repos matching SEARCH
 pkg -n SEARCH			search name only, list all matching pkgs
 pkg -g filezilla		get & install filezilla and deps
 pkg -a -g filezilla		ask to download filezilla and each of its deps
 pkg -a -la			ask to delete all downloaded packages
 pkg -a -e PKGNAME		install deps of PKGNAME, ask each time
 pkg -a -d qupzilla-1.2.0	ask to download qupzilla-1.2.0
 pkg -go filezilla		download filezilla & deps, don't install
 pkg -e PKGNAME			install all deps of PKGNAME, dont ask
 pkg -d qupzilla-1.3.1		download qupzilla-1.3.1 no questions
 pkg -l qupzilla-1.3.1		delete the downloaded qupzilla-1.3.1
 pkg -pb jwm			compile, build & install the 'jwm' package
 pkg -la			delete all downloaded packages without asking!
 pkg -li vim | pkg -ps -	Get info on all installed Vim pkgs
 pkg -li vim | pkg -wr -	Get repo of an installed Vim pkg 
 pkg -li | pkg -a -u -		Ask to uninstall installed packages one by one 
 pkg --dir2sfs /path/to/dir/	convert a local directory to a .sfs package
 pkg -i /path/to/file.pet	install pet package, include the extension!
 pkg --tgz2pet /path/to/file	convert a local .tar.gz file to PET package

And so on...

[sc0ttman]

Another fix that needs to be made:

Change the line ~1094:

Code: Select all

ash *.petbuild

to

Code: Select all

bash *.petbuild

Some .petbuild files in /usr/share/petbuild contains stuff like:

/usr/bin/{file1,file2}

I was using ash to run the petbuild scripts (in order to compile the source),
but I guess bash is required...

[sc0ttman]

musher0, what pup are you testing on? .. Bits of your DISTRO_** files are diff and unfamiliar to me ..

I'd like to test Pkg out on that pup... (and others)..

I will need a good, varied selection of pups to test..

Debian, Ubuntu, Slack, other .. All will have different repos that need supporting in /etc/pkg/sources-all

Some may have different ~/.packages/* files .. Will need to get a look at all the options!

[musher0]

Hi scotman.

I'm on this Pup:
https://augras.eu/documents/ws-default/ ... Os_de_base
Five months old already!

DpupStretch-7fr, despite the "fr" mention, is a bilingual French-English Pup.
I haven't tested all of it in English, but the LANG variable should default to
the language you choose on 1st run. I haven't removed anything, only
added the French locales. Should you need any translation, just holler!

(Contrary to the pups by petihar [Triton] and Médor [Slaxen] who remove
as much as possible of the English to try to provide French-only Pups.)

You have a choice of three kernels for DPupStretch-7fr on that download
page: the last number in the iso file name being the kernel version.

You may end up on 1st run with the wmx window manager, I can't
remember off-hand. If you find wmx confusing, do < xwin jwm > at the
initial black console, jwm is still there and can still be used.

Have fun!

~~~~~~~~~~~~~~

Thanks for the mnemonics lesson! I'll try, but I think I'll still need the
separate less panel in a corner for a few days while I'm getting used to
your "pkg".

~~~~~~~~~~~~~~

Will do the edit on line ~ 1094.

BFN.

[sc0ttman]

Pkg needs a cleaner way to get

pkg-name # vlc-1.3.4abc-i486-s700, vlc-nogui-2.3.4-noarch
pkg-ver # 1.3.4abc
pkg-name-only # vlc , mplayer, gtk+2,
pkg-arch # i486
pkg-build-number # 1 .. may be null
pkg-suffix # s700 .. may be null

It first involves getting the version in a cleaner way,
(one func to do the job, rather than snippets around the Pkg code)..

from split.sh (taken from new2dir)

Code: Select all

#difficult task, separate package name from version part... 
#not perfect, some start with non-numeric version info...
xNAMEONLY="`echo -n "$xPKGDIR" | sed -e 's/\-[0-9].*$//g'`"
#...if that fails, do it the old way...
[ "$xNAMEONLY" = "$xPKGDIR" ] && xNAMEONLY="`echo "$xPKGDIR" | cut -f 1 -d "-"`"