[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: package sectinos



Wichert Akkerman <wichert@cs.leidenuniv.nl> wrote:
> The topic of package sections has apparently come up once more on
> debian-devel. It seems everyone agrees that the current method of
> putting packages in one of 10 or so sections is not good enough for 
> the huge amount of packages we have accumulated.
> 
> There have been proposals of using keywords to make it easy to search
> for packages, and people suggesting that we make the sections more
> hierarchical and add subsections.

Have a look at my ideas on http://www.hairnet.demon.co.uk/moretags.html:


                           Functions and Interfaces
     _________________________________________________________________
   
   At the moment, the alternatives system, the packaging system, the
   virtual package names, the sensible-* scripts, the default X server,
   the kernel image and the default window manager settings are all
   seperate entities. I think they could all be more tightly intergrated.
   
   The default choice for the alternatives system is pre-deceided, the
   sensible scripts are similar, except they look at enviroment as well,
   while the default kernel, X server and windows manager are all
   decieded from questions in postinst scripts.
   
Function

   Debian has a lot of programs that do the same thing. These functions
   could be descriped with a functions tag, in the package file. For each
   package there could be more than one function. This tag would be
   slightly similar to the virtual packages idea, but more advanced.
   
   My basic example would be GNU Emacs. The functions tag could look like
   this:
   
   Functions: editor, emacs, info-browser, mua, calendar
   
   I am sure it does more, but I can not think of any. Here is a list of
   possible functions: (it is incomplete)
   
   editor
          Any editor capable of editing a file given as a parameter on
          the command line.
          examples: emacs, xemacs, vim, ed, nvi, jed, jove
          sub-functions:
          
        emacs
                A version of emacs. There are a great number of different
                versions of emacs, at the moment the virtual package
                `emacs' in Debian represents one a version of GNU Emacs
                or XEmacs. How strict should this function be? Do jove
                and zile qualify?
                examples: emacs19, emacs20, xemacs20, xemacs21, jove ??,
                zile ??
                
        vi
                A version of the BSD editor vi.
                examples: nvi, vim, elvis, vile
                
   pager
          Any pager.
          examples: less, more, most
          
   www-browser
          examples: lynx, netscape
          sub-functions:
          
        netscape
                examples: communicator, navigator
                
   mta
          Mail Transport Agent
          examples: exim, sendmail, smail
          
   mua
          Mail User Agent
          examples: mutt, elm, mailx

   mda
          Mail Deliver Agent
          examples: deliver, procmail
          
   news-reader
          examples: trn, slrn, tin, nn
          
   news-server
          examples: inn, cnews
          
   irc-client
          examples: ircii, bitchx, epic
          
   icq-client
          examples: zicq, micq, licq
          
   aol-chat-client
          examples: tix
          
   ftp-client
          examples: lftp, ftp, ncftp
          
   file-manager
          examples: mc, kfm, explorer
          
   calendar
          examples: emacs, netplan
          
   c-complier
          examples: gcc, bcc, gcc272
          
   awk
          examples: mawk, gnu awk
          
   info-browser
          examples: info, gnu emacs, pinfo
          
   man-browser
          examples: man-db, emacs, pinfo, info
          
   graphics-viewer
          examples: eeyes, imagemagik, xv
          
   display-manager
          examples: xdm, login.app, gdm, wdm
          
   window-manager
          examples: twm, fvwm, enlightenment, kwm, icewm
          
   xserver
          examples: xggi, xserver-*
          
   kernel
          (this one is a bit of a joke)
          examples: linux, hurd, bsd
          sub-functions:
          
        linux-kernel-image
        linux-kernel-source
        linux-kernel-headers
        linux-kernel-doc
                
   shell
          examples: bash, tcsh, ash, zsh
          sub-functions:
          
        sh-shell
                examples: bash, ash, zsh
                
        csh-shell
                examples: csh, tcsh
                
   term-emulator
          examples: xterm, rxvt
          
   I am sure there are more `functions', for examples there are loads
   more servers (irc, nfs, ftp, web, etc).
   
   Some can only really have one installed at a time, like the servers,
   but others could have multiple installed. So you could have loads of
   editors and web browsers. The main suggestion of this rant, is for
   them to have priorites that can be adjusted by the user, and the
   system administrator. So as a user I could run a dselect or apt like
   program with a list of packages and instead of selecting which to
   install, and which to hold, select priorites for the functions listed
   above. I might select emacs as my main editor, gnu emacs 20 as my main
   emacs, and vim as my main vi. But I could still have the others
   installed. I think this would be useful on a per machine and per user
   basis, so that as a power user I could select a heavy weight editor,
   and other users could select an easier to use one. It would be a handy
   tool for changing window managers. It could use a similar symlink
   system to the alternatives system, have cc as a symlink the the
   current C compiler and vi a link to the current vi clone. The selected
   linux-kernel-image could be made the default in lilo.
   
   There are some more questions though, what of the interface? I tend to
   use lynx on the console and netscape in X11, there should be some way
   of handling this.
   
Interface

   Differnet people use Debian in different ways. I like to think of
   myself as a bit of a console man, I tend not to use X11, but others,
   in the near future at least, will swear by gnome or kde, refusing to
   touch anything with a different interface. So why not give them an
   idea of the interface when selecting packages? Here are some first run
   ideas for interfaces with discriptions and example packages, in
   alphabetical order:
   
   athena
          The original X11 toolkit, ugly and hard to code. Note: Some X
          programs do not use any toolkit, they are in X11.
          examples: gnu emacs, xfig, xbill, most xbase-clients
          
   berlin
          Very new graphical user interface, possible replacement to X11,
          nowhere near finished.
          examples: none
          
   console-interactive
          I would like to differentiate different kinds of console
          interface, this is specifically a command line interface, not
          curses. Programs that do not run full screen.
          examples: ed, bash, gnuplot, ftp, gnupg
          
   console-non-interactive
          Your standard `no questions' asked applications.
          examples: gcc, dpkg, ls
          
   curses
          Full screen console stuff, ie most `modern' console programs.
          examples: mutt, lynx, slrn, dselect, aa
          
   emacs
          An emacs module. This will work anywhere emacs will.
          examples: calc, w3
          
   fb
          Framebuffer, new console graphics interface, not avaliable on
          some machines still.
          examples: pnmtofb, xserver-fb
          
   ggi
          General Graphics Interface, runs on top of KGIcon, X11, svga,
          fbdev.
          examples: xserver-ggi
          
   gnome
          GTK app, properly gnome intergrated, runs on X11, could include
          gnome-complient window managers, not linked to GTK.
          examples: gnome*, eeyes
          
   gtk
          GTK app not using gnome libraries, runs on X11.
          examples: gimp, mozilla
          
   headers
          Library development headers, none developers can exclude them
          from
          package listings which is nice.
          examples: lib*-dev
          
   html
          Documention in html format, if users dislike html formatted
          documention, they can decied not to list it. Note this is
          differnet from a interactive web interface program.
          examples: doc-linux-html
          
   kde
          K Destop Environment, linked against qt, runs on X11. Could
          include KDE complient window managers, not linked against qt.
          examples: kde*
          
   lesstif
          Motif/Lesstif programs, getting a bit old now, runs on X11.
          examples: netscape
          
   library
          A dynamic library, excludes development files and static
          version, should not include any binaries.
          examples: lib*
          
   perl
          Perl module.
          examples: lib*perl
          
   python
          Python module.
          examples: *python*
          
   qt
          Troll Techs qt widget set, NOT linked against kde libs, runs on
          X11
          examples: licq
          
   server
          Loads, reads config from file, waits, serves connections.
          examples: apache, ftpd, ircd
          
   svgalib
          I think this is i386 specific (not sure), graphics before fb
          and ggi
          examples: quake, doom, gnuplot, svncviewer
          
   text
          Documention in text format.
          examples: doc-linux-text
          
   web
          Web interface, becoming more popular, useful for controlling
          servers.
          examples: swat (Samba Web Administration Tool)
          
   x11
          X11 program without toolkit. They do exist.
          examples: xvncviewer
          
   xforms
          XForms widget library, non-free, runs on X11.
          examples: lyx, xisp
          
   Any number of these can be included in the Interface field, so for gnu
   emacs you would have:
   
   Interface: curses, athena
   
   Apt would be able to sort, or query on the Interface line, this would
   encourage a more consistent interface and would make the package list
   appear shorter. People decied on their prefered interfaces and apt
   only lists packages that use those interfaces.
   
   It should be possible to select a package for each function for each
   interface, or is that too complicated? Could I have a console editor
   appear, when I need an editor on the console, and a X11 editor appear
   when in X11?
   
   Another consideration is the fact that packages are not synoumous with
   binaries. A package can contain lots of different programs that
   function in different ways, maybe with different interfaces. Should
   the interfaces and functions be on a per binary basis? Would that be
   easier or possible.

-- 
I consume, therefore I am

Attachment: pgpKiMnSby9vX.pgp
Description: PGP signature


Reply to: