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) _______________________________________________ Debtags-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debtags-devel
