[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.

   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
   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)
          Any editor capable of editing a file given as a parameter on
          the command line.
          examples: emacs, xemacs, vim, ed, nvi, jed, jove
                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 ??
                A version of the BSD editor vi.
                examples: nvi, vim, elvis, vile
          Any pager.
          examples: less, more, most
          examples: lynx, netscape
                examples: communicator, navigator
          Mail Transport Agent
          examples: exim, sendmail, smail
          Mail User Agent
          examples: mutt, elm, mailx

          Mail Deliver Agent
          examples: deliver, procmail
          examples: trn, slrn, tin, nn
          examples: inn, cnews
          examples: ircii, bitchx, epic
          examples: zicq, micq, licq
          examples: tix
          examples: lftp, ftp, ncftp
          examples: mc, kfm, explorer
          examples: emacs, netplan
          examples: gcc, bcc, gcc272
          examples: mawk, gnu awk
          examples: info, gnu emacs, pinfo
          examples: man-db, emacs, pinfo, info
          examples: eeyes, imagemagik, xv
          examples: xdm, login.app, gdm, wdm
          examples: twm, fvwm, enlightenment, kwm, icewm
          examples: xggi, xserver-*
          (this one is a bit of a joke)
          examples: linux, hurd, bsd
          examples: bash, tcsh, ash, zsh
                examples: bash, ash, zsh
                examples: csh, tcsh
          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.

   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:
          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
          Very new graphical user interface, possible replacement to X11,
          nowhere near finished.
          examples: none
          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
          Your standard `no questions' asked applications.
          examples: gcc, dpkg, ls
          Full screen console stuff, ie most `modern' console programs.
          examples: mutt, lynx, slrn, dselect, aa
          An emacs module. This will work anywhere emacs will.
          examples: calc, w3
          Framebuffer, new console graphics interface, not avaliable on
          some machines still.
          examples: pnmtofb, xserver-fb
          General Graphics Interface, runs on top of KGIcon, X11, svga,
          examples: xserver-ggi
          GTK app, properly gnome intergrated, runs on X11, could include
          gnome-complient window managers, not linked to GTK.
          examples: gnome*, eeyes
          GTK app not using gnome libraries, runs on X11.
          examples: gimp, mozilla
          Library development headers, none developers can exclude them
          package listings which is nice.
          examples: lib*-dev
          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
          K Destop Environment, linked against qt, runs on X11. Could
          include KDE complient window managers, not linked against qt.
          examples: kde*
          Motif/Lesstif programs, getting a bit old now, runs on X11.
          examples: netscape
          A dynamic library, excludes development files and static
          version, should not include any binaries.
          examples: lib*
          Perl module.
          examples: lib*perl
          Python module.
          examples: *python*
          Troll Techs qt widget set, NOT linked against kde libs, runs on
          examples: licq
          Loads, reads config from file, waits, serves connections.
          examples: apache, ftpd, ircd
          I think this is i386 specific (not sure), graphics before fb
          and ggi
          examples: quake, doom, gnuplot, svncviewer
          Documention in text format.
          examples: doc-linux-text
          Web interface, becoming more popular, useful for controlling
          examples: swat (Samba Web Administration Tool)
          X11 program without toolkit. They do exist.
          examples: xvncviewer
          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: pgpI8c87HCvAZ.pgp
Description: PGP signature

Reply to: