Proposal: Debian Package Information Displayed Using Eclipse

[Don Estberg <destberg1@earthlink.net>]

I'd like to create a package that is a GUI frontend to information
about all installed Debian packages.  I'd appreciate any comments about
whether this is a reasonable thing to do and any suggestions about what
features this package should have.

The reasons I want to do this are
  
+ In the process I'll learn a lot about Debian package management.  I've
  been using Debian Linux for over a year and come from a UNIX
  background, but have more to learn before I feel like an expert. 
  
+ Show that Eclipse (eclipse-sdk_2.1-5_all.deb, www.eclipse.org) can be
  used as a base for the creation of an non-IDE application.  Eclipse
  allows creation of plugins written in Java.  It has a Standard Widget
  Toolkit that is better than Swing, and it has an API for tools that
  analyze, manipulate and display various lists, trees, tables and text.
  Information is displayed in "views", and these views are grouped into
  "perspectives".

+ Create something useful for the Debian Linux community.

There are 3 ways the initial features of this package would be useful:

1.  Help find a package

  A list of package names (with a way to jump to those starting with
  each letter of the alphabet) is similar to what is available now.
  Likewise, one can use a regular expression to search either the names
  or the description.  Also, one can filter packages based on section or
  tag classification.

  More unique, a filter can be created by setting one or more of the
  following:

        File that is part of the package
        Configuration file
        Library or library routine that is part of the package
        Maintainer
        Distribution
        Installed on, before or after a given date
        Leaf/non-leaf package (any package depend on this one?)

  In addition, one should be able to create a personal annotation file
  for each package, and to be able search for a package based on a
  regular expression in that file.

2.  Understand how packages are related

  Graphic tools can help visualize where a package is positioned in the
  dependency hierarchy.  Current tools show the "depends on" side, but
  the "required by" side is more difficult.  Also graphic tools make it
  easy to dynamically extend the level, and, for a potential package,
  show what is and is not installed.

  Tables can help compare a specified set of properties for a filtered
  set of packages.

3.  Learn about a specific package

  When you get (or are about to get) a new package, with a little
  searching, you can find if there is a doc-base file, a man page, an
  info entry or other documentation available.  But it would be much
  easier just to double click on something and have an xterm or a
  browser pop up with that documentation.

  If you can remember all the right commands and options, you can find
  all sorts of properties for a package that you have or you may want
  to install.  Some of these properties only apply to certain types of
  packages.  I don't know the correct property name for some of these.

        alternatives
        architectures
        bin/src
        bin/src package for this src/bin
        bugs
        build target directory
        commands
        configuration files
        conflicts
        depends on
        description (long)
        description (short)
        distribution
        doc-base files
        doc directory
        error status
        essential/non-essential
        filename (deb)
        files
        free/non-free/contrib
        info documents
        install directory
        installed size
        leaf/non-leaf (all)
        leaf/non-leaf (installed)
        libraries
        library routines
        maintainer
        man pages
        priority
        provides
        recommends
        replaces
        required by
        section
        statoverrides
        status change date
        status (current)
        status (desired)
        suggests
        tags
        US/non-US
        version
        virtual/non-virtual
  
The above information would form the first perspective of my proposed
package.  I'm thinking about naming the package dpkgue (dpkg using
Eclipse).  My progress so far has been more on he Eclipse side - finding
how to cleanly base my application on an already installed Eclipse
without picking up all the IDE plugins. 
  
If all goes well, I can think of a couple of other perspectives.  One
uses the junit capabilities of Eclipse.  After doing an update, you'd
like to know if the packages that you updated are still working on your
computer (of course, easier said than done).  Another perspective would
just duplicate dselect functionality.

Thanks for any comments,
Don Estberg