role:: questions

[Benjamin Mesing]

Hello,

all statements made below represent my personal opinion, rather than
absolute answers. To keep answers short I spared the "I believe.."
phrases.


> * 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?

Isn't that role::metapackage?


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

I would go with role::program

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

I think it depends on the intention of the program. If the php files are
meant to be executed as standalone applications, I would say yes.


> * 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?

I'd vote for data if the user can select those in fonts in his office
suite. Perhaps tagging with both tags is an option?


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

Perhaps 
        role::driver	Hardware Drivers and Kernel
would be needed?



> * are unionfs-modules-2.6.X-foo 

Could go for ::driver?


> and libapache2-mod-foo ::plugin?

Yes.


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

Yes. 
The tagname is misleading though, perhaps devel::debugging would be
better suited?


> * 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...?)

I'd say that libraries that represent both the developer interface and
the shared library (like e.g. perl libs and java libs) should be tagged
with both, ::devel-lib and ::shared-lib.


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

::documentation


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

Perhaps the online editor hides role::meta since nothing is tagged that
way yet?
I would say ::dummy packages are those only for transitional purpose.
The other ::meta are those that intend to stay. 
I would keep both tags.


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

Packages where the main focus is to provide a program to be executed
should be tagged role::program. [your description]

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

Replace role::dummy with role::meta.

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

Good.

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

I wouldn't refer to neither role::app-data nor role::plugin for
similarity, but only for distinction.

        Packages tagged role::data provide some data that is directly
        used by the user. This is different form app-data which contains
        data which is usually tied very closely to a special program.
        E-books are the classic example for role::data.


> * 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).

To narrow ::documentaion only to Debian-doc seems to tight. Perhaps
narrowing it to computer related subjects (running and developing a
computer system) would be better?


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

Packages whose main purpose is to provide the source of the program (or
even of some data). Often those packages cannot be shipped in binary
form, and thus contain only a *-source package.

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

      * 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. For
        many non-C programming languages (e.g. Java, Perl) libraries are
        both, role::shared-lib and role::devel-lib.



Regards Ben