OpenBSD Journal

Developer Blog - landry@: pkg_mgr, a tool to manage and browse packages

Contributed by jj on from the cursing-them-ports dept.

Landry Breuil (landry@) sent us a note about his new project and the impact it may have for your everyday ports usage.
After using OpenBSD for a few years, I was still missing a higher-level tool to manage installed packages and browse available ones, but I didn't really like pbrowser, it was too tied to a graphical toolkit. I first started to look at a tool written by a friend, pkg_select, but its C code was hard to understand, and it was aimed at pkgsrc.

Then I remembered the existence of sqlports from Marc Espie (espie@) and found out that no one was using it. And as pkg_* tools are written in Perl (and I like Perl!), I decided to write my own curses-based tool on top of sqlports with Perl. I first tried to use one of the available ORM in the ports-tree (like DBIx::Class and Rose::DB), but found out that it was too slow for the few SQL queries I needed, so I ended writing my own plain DBD::SQLite model. I decided to strongly separate the interface from the model backend, so it would be easier to write an interface in something else that uses curses.

It quickly grew into something usable, and I rapidly added all the essential features I needed, but I kept it simple (atm it's only 650 lines of Perl). So here's for the story.. now pkg_mgr is a user-friendly graphical tool which allows you to manage installed packages, browse available packages by categories, and finally install/uninstall packages (using sudo, hence you don't need to run it as root). At the moment, only a simple curses interface is available, but a Gtk2 GUI is planned soon. It is in no way intended to replace existing working tools, however it uses them extensively. It is just a more high-level interface to them (hence you'll need PKG_PATH set if you want to install packages). At the moment, you don't need the ports-tree installed to use it, but for future use it would be useful.

    Some kind of roadmap and ideas for the future :

  • if the ports-tree is available, permit to build packages, show port Makefile or packing-list
  • permit to customize PKG_PATH by selecting a mirror in ftp.html .
  • handle SIGWNCH
  • write a readline-based interface
  • differentiate between installed and selected packages
  • handle flavors/multipackages better
  • handle available updates (maybe tie it to update-notifier ?)
  • fix bugs (I'm sure there are plenty!)

It relies on databases/sqlports for the internal database, so you will need to have an up-to-date version installed for pkg_mgr to work well.

e.g if you track -current, each time you update your ports-tree and packages, do something like this:
 # pkg_add -ui -F installed sqlports
It uses Curses::UI, you will need a recent version of it (-current or 4.3 are okay, 4.2 or older are not because Curses::UI with dialog support is available only since a recent update. This limitation may disappear in the future)

If you only want to test it, you can install dependencies (pkg_add p5-Curses-UI p5-Curses p5-Term-ReadKey sqlports p5-DBD-SQLite), download source, untar it, and run it directly from source with ./pkg_mgr. Or just use the port which will be soon committed in sysutils.

I have lots of ideas for this new tool, but I need user feedback first, so I'd be happy to have comments and rants about it.

More information (source and screenshots) are available here; http://gruiik.info/pkg_mgr.html.

(Comments are closed)


Comments
  1. By sthen (2a01:348:108:155:20a:e4ff:fe2d:99ee) on

    It's not going to be for everyone, but I like it, I find it a lot quicker and simpler than looking through /usr/ports or openports.se if I'm looking for something and I don't remember the name.

  2. By Anonymous Coward (89.77.162.243) on

    looks interesting, cheers!

  3. By Anonymous Coward (213.185.19.190) on

    Re: SIGWINCH - don't use it.

    Comments
    1. By Matthias Kilian (91.3.39.143) on

      > Re: SIGWINCH -

      There's nothing wrong with SIGWINCH handlers in programs. Theos warning was about a SIGWINCH handler in libncurses.

    2. By Devin Smith (drs) on

      > Re: SIGWINCH -

      I understand that SIGWINCH is bad but I'm not sure how we
      are supposed to handle a screen resize in OpenBSD curses.

      I looked at resizeterm and wresize but still don't
      understand how an application is notified of a resize event
      if SIGWINCH is not sent.

      Comments
      1. By Janne Johansson (jj) on Old amiga fart.

        > > Re: SIGWINCH -
        >
        > I understand that SIGWINCH is bad but I'm not sure how we
        > are supposed to handle a screen resize in OpenBSD curses.
        >
        > I looked at resizeterm and wresize but still don't
        > understand how an application is notified of a resize event
        > if SIGWINCH is not sent.
        >

        You can install a signal handler for SIGWINCH yourself and handle the signal when it comes.

        Comments
        1. By Landry Breuil (gaston) on http://gruiik.info

          > > > Re: SIGWINCH -
          > >
          > > I understand that SIGWINCH is bad but I'm not sure how we
          > > are supposed to handle a screen resize in OpenBSD curses.
          > >
          > > I looked at resizeterm and wresize but still don't
          > > understand how an application is notified of a resize event
          > > if SIGWINCH is not sent.
          > >
          >
          > You can install a signal handler for SIGWINCH yourself and handle the signal when it comes.
          >

          In fact it's as simple as adding:
          $SIG{'WINCH'} = my_redraw_handler;

          Now i have to fiddle with Curses::UI to make it redraw correctly the screen.

  4. By Anonymous Coward (24.37.242.64) on

    Awesome, great work!

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]