role:: questions

[Justin B Rye]

I seem to have developed a set of usage opinions about the role::
facet which might translate into tips, but I don't know whether
anybody else shares them, so I'd like to try fishing for comments.

TEST-CASE PACKAGES

I'm starting with some tricky cases in the hope that they'll leave
you with answers in mind that _don't_ match mine! 

* gcc exists as a sort of "escalator" dependency package to keep
  whatever-C-compiler-is-currently-default installed, but it isn't
  empty - it contains the /usr/bin/gcc symlink, so you need it for
  compiles.  Is gcc role::dummy?

* the package mailreader contains CGI scripts, but puts nothing in
  any $PATH directory.  Is it a ::program, a ::plugin, or what?

* if a package contains nothing but .php files, is that a ::program?

* similarly, gnustep-foo.app packages don't put an executable on my
  $PATH, they use symlinks to wrapperscripts, and hide their actual
  contents under /usr/lib/GNUstep - ::program?  ::plugin?

* are font-packages ::data or ::app-data?  Or do they vary?

* linux-headers-2.6.X-foo must be ::devel-lib, but how about
  linux-image-2.6.X-foo - ::program?  ::TODO?  Or what?

* are unionfs-modules-2.6.X-foo and libapache2-mod-foo ::plugin?

* libfoo-dbg is ::shared-lib plus some devel:: tag or other.  They
  seem to be getting devel::debugger - is that right?

* is cl-foo implemented-in::lisp role::shared-lib, like its 
  equivalents in ::perl or ::python or the like?  Or are they
  role::devel-lib?  (And if it varies from one programming language
  to the next, how about libfoo-ruby, -ocaml, -lua, -cil...?)

* is debian-policy ::documentation or ::data?  How about
  doc-linux-text?

ATTEMPTED USAGE GENERALISATIONS

This is the nearest I can get to a set of guidelines for the role::
tags.

* any package that exists purely for the sake of the dependencies in
  its control file is role::dummy.  It may pull in suites, it may
  ensure exactly the right member of a set is installed, it may be a
  name-change-handler package, or it may be something slightly more
  complicated.  One of the commonest inter-release problems is that
  contentful packages get replaced by empty packages of the same
  name, or vice-versa.

* I've just noticed that my local vocabulary file distinguishes a
  role::metapackage, but the online editor doesn't.  Is the idea
  that it has been merged into role::dummy?  (If so, good.)

* packages that put executables on $PATH are role::program.  If they
  put them elsewhere - in run-parts directories, /usr/lib/cgi-bin,
  /usr/share/emacs/site-lisp etc - things aren't as clear.  Such
  packages usually include some straightforward utilities too, but
  there's room for debate about whether they "count" - if foo-data
  contains 10MB of XML, it's role::app-data, even if it does come
  with a shell-oneliner /usr/sbin/update-foodata.

* you'd think role::shared-library packages would be easy to spot,
  but unfortunately their names don't all begin with or even contain
  the string "lib".  Nor are libfoo-{bin,common,dev,doc} usually
  libraries, and a plain libfoo package may turn out on closer
  examination to be a role::dummy to pull in libfoo42. 

* role::app-data packages are distinguished from ::shared-lib ones
  by content - rather than loadable code, they contain XML, images,
  config-files, TeX stylesheets or other infrastructure required at
  runtime.

* role::plugin is mostly distinguished from role::shared-library by
  dependency strength: if it provides code modules needed for a
  program to work, it's ::shared-library, but if they just make it
  more flexible, and particularly if they're specific to that one
  app (so the dependency runs backwards), it's ::plugin.  Plugins
  may even cause new icons to appear on a desktop, but they aren't
  role::program unless they run out of /usr/bin.

* packages tagged role::data are like ::app-data but are provided
  directly for the benefit of users rather than for any particular
  package.  They're like role::plugin, but static data rather than
  libraries.  E-books are the classic example.

* role::documentation is for packages that actually contain docs
  for Debian-relevant subjects - foo-doc packages are
  ::documentation, bibles are ::data, but the borderline is unclear.
  Manpage-editors and infrastructure packages like dwww aren't
  role::documentation or made-of::documentation, they're
  works-with::documentation (or would be if that existed).

* role::source packages let you "apt-get install foo-source" - it's
  effectively like "apt-get source foo", except that it goes through
  the package database, so it can be used as a build dependency.  Or
  at least, I think that's the idea... also I suppose some nonfree
  packages exist only in this form for license reasons.

* role::devel-lib packages provide code for use at build-time, other
  than actual package source code.  Usually they're recognisable by
  the fact the package name ends in -dev, but there are exceptions
  like manpages-dev (::documentation) and xutils-dev (::program),
  plus plenty of ::dummy dev-packages.

So, how close am I to something people agree on?
-- 
JBR
Ankh kak! (Ancient Egyptian blessing)