pkgtool-0.4 CLI package manager

[Nathan F]

EDIT: new version uploaded

This is my CLI package manager which has been languishing unused in svn for months now. I've brushed it off, updated it to reflect the direction that PET packages are going, and greatly improved the dependecy tracking and overall ease of use. This is not quite like apt or yum yet, but since it is smaller and way faster that's just fine with me. Actually I think it works quite well. For those interested in following the development of this project the code can always be found in the Puppy subversion repository.

Main points of interest:

• * Way faster at installing and removing packages than PETget.
  * Simple and easy to use.
  * Well commented code that should be fairly easy to maintain.
  * Accepts a variety of commandline options and should be able to work with external programs and gui's, as has been tested with MU's psi installer and KLH's dotpup downloader.

Still to do:

• * Complete handling of PET packages, currently it handles .tar.gz unleashed packages (which are still being used as of 2.13 anyway).
  * Better documentation for developers.
  * Better integration capabilities with external scripts.

What is changed in this version:

• * The dependency tracking has been totally rewritten.
  * When installing a package with multiple dependencies thay are now added to a queue and processed as a single function, rather than one at a time.
  * Going along with the above, there are quite a few fewer points of user interaction, so everything is more streamlined.
  * Running ldd on all executables is now optional, as we now have dependencies listed in the package database already. This speeds things up even more.
  * Various visual improvements. The screen is cleared between stages for a cleaner look in the console.

This is now beta quality IMO, and is almost ready for all users. Right now I would recommend it for those with intermediate to advanced skills, just to be on the safe side. This is a .tar.gz unleashed package, so either install using PETget or untar it manually and copy the files over.

Note - for Puppy-2.xx only, Puppy-1.xx would require too many differences in the installation code to support both platforms.

Nathan

[Nathan F]

Ther was a bug in the dependency parser that I did not see yesterday, preventing it from checkingh dependencies recursively. I uploaded a new version, which should now work as advertised. I tested it with my xfce4_all metapackage from the grafpup repo, in Grafpup alpha, and it caught every dependency (quite a few).

Nathan

[Nathan F]

I finally got around to wrapping a gui around this, although it's nowhere near complete. At present it presents a two pane selection window very similar to pupget/petget and can only install or uninstall packages. Very basic but also very fast, and it requires almost no user interaction once you decide to apply the changes. That fact alone makes it quite different from petget. It is especially well suited to older and slower machines.

I do have to review the code a bit to make sure it runs in Puppy just as well as it does in Grafpup, before I release a package. This is not intended to be a total replacement for petget, but a lightweight and easy to use alternative.

Nathan

[klhrevolutionist]

Great news Nathan ! I'm a little skeptical as you mentioned it is 2-paned (pup/pet get) ......

Maybe post a screenshot for others to see ?

[Nathan F]

Actually right now the part of the gui that is finished looks pretty much just like the pupget/petget package selection window, except with some different explanatory text. So a screenshot would be wasted here. What I consider the improvements are in how the choices are handled after the user presses the Apply button. Nevertheless I'll attache a couple screenshots anyway. The first one shows the two pane window, the second shows the single confirmation window showing all of the changes that are about to be applied (including dependencies). Once you press OK there, then a small rxvt window opens and all of the packages queued for installation are installed, followed by another one in which the packages queued for removal are processed, one after the other until finished. No further popup windows to get in the way or to slow you down, or ask for confirmation.

A plan I have for the future, since pkgtool already has a good search feature, is to create a secondary gui where you enter a search query and it pops up a list of matching packages. You would then be able to add any of the resulting packages to the install or remove queues, and either do more searching or apply the changes right away. The idea is on the burner but not coded yet, however I made it flexible enough that it shouldn't take any amount of recoding. Rather it will be just adding to what is already there, so once started it should come together fast.

Also in the works will be a dependency checker for already installed packages, as in pupget/petget, and local package installation. Basically all of these features will share the codebase that is already in place and be rather like adding extra modules to the program.

Of course there have been nicer package selection gui's out there already, like MU's PSI, which is still quite marvelous. However as I mentioned this is quite simple and easy, and also much faster than any other package installation program we have currently short of using the command line. And in case anyone is wondering I will be going through and changing references to Grafpup into Puppy references in any Puppy version I might put up.

Nathan

[Lobster]

This is good.

I find the limitation of PetGet is how few programs (compared to what is available) are there.

The search would be welcome and the inclusion of dotpets if we have a depository? Does your program download library dependencies (if required) or is that just a Petget feature and too advanced for your program?

You could do with some testers for this. Good job by the looks of it

[Nathan F]

I find the limitation of PetGet is how few programs (compared to what is available) are there.

If the community gets behind Barry on the concept and starts making pet packages rather than dotpups, we could quickly fill up several repositories.

The search would be welcome and the inclusion of dotpets if we have a depository?

As of right now this would be limited to 'official' packages, whether they are in the Puppy repo or the Grafpup repo depending on which distro is being run. I have a few ideas for how to expand the scope, but they would take a bit of effort to implement.

Does your program download library dependencies (if required) or is that just a Petget feature and too advanced for your program?

Oh, it does download dependencies. In fact, this is something I think it does better than PETget does in a lot of ways. When PETget installs a package, it checks dependencies as it is installing the package, and then adess them to a queue for installation after the main transaction has run. Also, it asks for confirmation for every package that is being installed, and also asks you to pick a mirror to download from. All in all that's a lot of dialog boxes, plus it pops up the annoying 'Processing, please wait..' window right in the middle of the screen, which stays on top unless you know how to kill it. Mine checks the dependencies before it downloads anything, queue up all the packages, and then asks you for confirmation once. As soon as you verify that in fact you want to apply the changes, it downloads and installs all the queued packages including dependencies, and then removes the ones that are slated for removal, all in the background without asking for further confirmation. And all a whole lot faster as well.

There are still things I'm working on to make it better, and PETget still has some distinct advantages over pkgtool and Gpkgtool. PETget seems to be able to parse the dependency information slightly more reliably right now, although there are only one or two packages that trip up pkgtool. Also, PETget can check the depndencies of an alien package as well if it contains a .specs file, and then download and install them if they are official packages. This is planned for pkgtool as well but not yet implemented.

The best way to evaluate the relative merits is going to be to try the program out of course, and it debuts in the next development snapshot of Grafpup. I'm currently uploading the isos to the bubbleletter mirror so be advised they will be available in a couple hours time. I'd like for people to give the program a good test and report back to me any issues they run into. In particular by installing packages that have a lot of dependencies. For instance, there is an xfce4_all package that has all of the componenets of the xfce-4.4.0 desktop as dependencies, or you could install one of the audio applications like Hydrogen or Audacious that require a few additional libs.

I'm open to suggestions but remember that I will continue to go slowly on this project. Also, there are some ideas I may reject as making for too much complexity.

Nathan

[gliezl]

Hi Nathan,

Will Slackware packages (*.tgz) work with your pkgtool? For example, I want to install bind-1.2-i386.tgz or squid-2.4-i386.tgz, will it be compatible with Puppy?

Cheers

Any updates on your onebone?

[MU]

Hi Gliezl, nice to see you again

No, Slackware packages have a different folderstructure, and include an own installscript.
Apart from that, they work fine in Puppy.

Manual installation:
Extract it somewhere.
Move doinst.sh one folder up and run it.
It creates some symlinks in the new subfolder "usr", and sometimes does more.
Then copy those subfolders like "usr" to the Puppy filesystem or make a dotpup.

Automatic installation:
Use gslapt:
http://www.murga-linux.com/puppy/viewtopic.php?t=11929

Mark

[Nathan F]

I need to get back to pkgtool and get the version in subversion more up to date. I've made a few important changes to the version in Grafpup that I haven't posted to the subversion repo because a few other changes break compatibility with Puppy right now.

Regarding Slackware packages I could possibly support that in the future, but I see some issues with doing so. First off, I've seen several install scripts in Slackware packages that would cause some problems in Puppy. Second is that some file locations do not correspond, which could also cause some problems. As just one small example, slackware keeps some icons in /usr/share/pixmaps, and if you were to install a Slackware package into Puppy without taking that into account it might overwrite the symlink to /usr/local/lib/X11/pixmaps from that location, breaking some scripts which will then miss their icons. There are other problems too. I think the best way right now is to install Slackware packages manually (if at all, since they really should be built against our libraries with our compiler anyway) so as to avoid any problems caused by incompatible file locations or install scripts.

As for Onbone, I just ran that iso not long ago and noticed how badly it does need an update. I tried installing some extra packages with pkgtool and found that they didn't exist anymore on any server, and that a few others no longer work because the libraries they compiled against have been updated. So yeah, I think I'll do another one pretty soon, although I can't set a time frame because of how busy I usually am these days. Any comments or suggestions on what you'd like to have in it would be helpful.

On a side note if I do create another Onbone it may grow a bit over the last one because that iso was using lzma compression for it's squashfiles. But the part that loads into ram is likely to be smaller because we have since started using zdrv to store drivers in.

Nathan

[BarryK]

No, Slackware packages have a different folderstructure, and include an own installscript.
Apart from that, they work fine in Puppy.

If you convert a Slackware package to PET with 'tgz2pet' then use PETget to install it, the Slackware install script is executed. For further info, see:
http://www.puppyos.com/development/pack ... gement.htm