role:: questions

[Justin B Rye]

Benjamin Mesing wrote:
>> * 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.

I often find it hard to tell from the package descriptions.  I was
hoping it might be possible to work it out from the contents.
 
>> * 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?

If multiple roles are allowed there's a risk that some -common
packages will end up claiming every role:: tag that's going!
 
>> * 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?

Possible, though I'm not sure about the name.  "Software to be run
outside userspace"... should it include things like mbr and
memtest86+ that "run" even outside Linux kernelspace?

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

Which programming languages would you say have library packages that
are pure runtime dependencies, then?  (Personally I think Perl is
one - see end). 

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

No, role::metapackage is all through /var/lib/apt/lists/*_Packages.
I think it's vestigial rather than rudimentary.

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

The trouble is that it isn't a simple two-way split, it's at least
four-way, with
* one-off rename-handlers (eg ph-f-f-iceweasel)
* permanent escalators (eg linux-image-2.6-k7)
* OR-ing dependency-packages (eg gs)
* AND-ing suite-pullers (eg kde-yes-give-me-everything-please)
Rather than try to classify these different types here I'd rather
see a single role:: tag for all of them.

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

[Somebody else's description]  What I'm trying to do here is work
out whether emacs modes, cgi-scripts etc provide "a program to be 
executed" or whether they're plugins for the frameworks they hook
into.  The $PATH rule of thumb would be a nice easy one to check.

Alternatively we could keep the off-path executables under
role::program and reserve role::plugin for the things like
gkrellm-foo (so that plugins are optional-extra libraries that
enhance the functionality of a program).

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

The connection to ::plugin is only in the fact that no app is going
to depend on them; you may be using a specialised e-book-viewer
framework, but that doesn't make it ::app-data.  By the way, perhaps
we should say "e-texts", not "e-books", since those are often in
peculiar and/or proprietary formats (see eg libeb7).
 
>> * 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?

I tend to agree that things like HOWTOs deserve to be treated as
::documentation even if they aren't absolutely Debian-specific or
the -doc member of a package family (I'm not sure why I phrased it
as if I was arguing against that).  There are still some cases where
I might be persuaded either way, though; eg the c++-annotations-*
family, which is somewhere between a "c++-doc" and an e-text that
just happens to be a programming coursebook. 

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

Not true at least for Perl (which is the closest to programming I
ever get): I can produce a script that uses module Foo::bar without
ever installing libfoo-bar-perl locally.  It's run-time only, not
(package) build-time.
-- 
JBR
Ankh kak! (Ancient Egyptian blessing)