FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-27-2009, 10:48 AM
Enrico Zini
 
Default Making some tags mandatory

[if help is needed with following the proposal below: a list of tags and
their description can be found at:
* http://debtags.alioth.debian.org/tags/vocabulary.gz
* /var/lib/debtags/vocabulary (if you have debtags installed)
* http://packages.debian.org/about/debtags (formatted on the web)
and can be searched with 'debtags tagsearch' or using the tag editor
at http://debtags.alioth.debian.org/edit.html in the 'all' and
'search' views]

Hello,

The way I see it, the last thread on sections has opened a bit of a can
of worms: now first everyone will want a section for their favourite
topic, then there is going to be a fight on which one to pick in case
packages that could belong to more than one section. Been there, done
that

While I see a list of well defined sections that could still make a lot
of sense and carry a very practical meaning (namely, libs, libdevel,
deprecated (former oldlibs), debug, locale, kernel and data (for
foo-data packages)), other sections are clearly minor and belong
elsewhere (like the programming language for a library).

You said that debtags cannot yet replace sections because it is not
assured that all packages have tags: you have a point. Let's take care
of it.

I say that with the number of tags in the vocabulary approacing 600, we
just can't ask maintainer, ftp-masters, or anyone really, to know all of
them; but I can certainly come up with a 'core' list of tags that are
well defined enough, and that we can safely expect maintainers to know
about.

This is what I have to offer:


* The proposal

At the end of this mail is the list that I propose: it's 138 of them,
but grouped as they are, they should be quite clear to grasp. I
consider these groups of tags (debtags calls them facets) to be mature
and uncontroversial enough to be made official and to ask maintaners to
take care of them.

Besides proposing the tags, I offer to implement these three features
within a month from when we agree on a way for maintainers to add them
to the control file:

- For packages with no tags in the control file, take the tags from the
review tag set as we have now
- For packages with tags in the control file, take tags in facets
{role, implemented-in, devel, interface, uitoolkit, accessibility,
admin} from the control file, and all the other facets from the
reviewed tag set.
- Provide a way for maintainers to show differences between the tags in
their control file and the submissions on the debtags web interface,
to be used as a sort of hint

I also offer to write lintian tests to ensure some consistency (role::*
must be there, implemented-in::* must be there if role:rogram is
there, and so on).

Note that this proposal can be implemented right now, as it introduces
new functionality without interfering with the existing one.


* Future developments

In the future more groups of tags can become 'core', after a round of
discussion, polishing, and testing. This discussion and polishing can
be done in the debtags side, without bothering/boring ftp-masters.

Tags first in the line to become core could be, for example, game::*,
hardware::*, mail::*, web::*, x11::*.

Some other groups of tags (biology::*, field::*, junior::*, made-of::*,
protocol::*, scope::*, suite::* and more) are probably better left to be
managed by groups of field experts. The gnome/kde team is probably
better than any single maintainer in deciding what should have the
suite::gnome/kde tag. Similarly, debian-med or debian-science people
can be called to have a say on tags of their interest.

Also, some tags like those in use::* or work-with::* are better assigned
the other way round, with people picking one tag and working to make
sure that the list of packages with that tag makes sense.

I am happy to come up with a workflow that allows such groups to have
the final say on their tags, and get the result integrated with the
rest: there are already several items in my todo-list that go in this
direction. Maybe, even if game maintainers will easily be able to pick
a game::* tag, we will even decide that it will make more sense, for
consistency, that game::* tags will be managed by the Debian Games team.

But this is for the future. For now, let's stick to the short term
proposal.


* The list

Role of the package in the archive (mandatory for all packages):

role::app-data - Application Data
role::data - Standalone Data
role::debug-symbols - Debugging symbols
role::devel-lib - Development Library
role::documentation - Documentation
role::dummy - Dummy Package
role::kernel - Kernel and Modules
role::metapackage - Metapackage
role:lugin - Plugin
role:rogram - Program
role::shared-lib - Shared Library
role::source - Source Code

Language that the package is implemented in (mandatory for all packages
mostly consisting of software):

implemented-in::ada - Ada
implemented-in::c - C
implemented-in::c++ - C++
implemented-in::c-sharp - C#
implemented-in::ecmascript - Ecmascript/Javascript
implemented-in::fortran - Fortran
implemented-in::haskell - Haskell
implemented-in::java - Java
implemented-in::lisp - Lisp
implemented-in::lua - Lua
implemented-in::ml - ML
implemented-in:bjc - Objective C
implemented-in:caml - OCaml
implemented-in:erl - Perl
implemented-in:hp - PHP
implemented-in:ike - Pike
implemented-in:ython - Python
implemented-in::r - GNU R
implemented-in::ruby - Ruby
implemented-in::scheme - Scheme
implemented-in::shell - sh, bash, ksh, tcsh and other shells
implemented-in::tcl - Tcl, Tool Command Language

User interface (mandatory for all packages mostly consisting of
software):

interface::3d - Three-Dimensional
interface::commandline - Command Line
interface::daemon - Daemon
interface::framebuffer - Framebuffer
interface::shell - Command Shell
interface::svga - Console SVGA
interface::text-mode - Text-based Interactive
interface::web - World Wide Web
interface::x11 - X Window System

User interface toolkit (for packages with tags interface::{3d,
text-mode, x11}):

uitoolkit::athena - Athena Widgets
uitoolkit::fltk - FLTK
uitoolkit::glut - GLUT
uitoolkit::gnustep - GNUstep
uitoolkit::gtk - GTK
uitoolkit::motif - Lesstif/Motif
uitoolkit::ncurses - Ncurses TUI
uitoolkit::qt - Qt
uitoolkit::sdl - SDL
uitoolkit::tk - Tk
uitoolkit::wxwidgets - wxWidgets
uitoolkit::xlib - X library

Role in the context of software development (as needed):

devel::bugtracker - Bug Tracking
devel::buildtools - Build Tool
devel::code-generator - Code Generation
devel::compiler - Compiler
devel::debian - Debian
devel::debugger - Debugging
devel::doc - Documentation
devel::docsystem - Literate Programming
devel::ecma-cli - ECMA CLI
devel::editor - Source Editor
devel::examples - Examples
devel::i18n - Internationalization
devel::ide - IDE
devel::interpreter - Interpreter
devel::lang:ada - Ada Development
devel::lang:c - C Development
devel::lang:c++ - C++ Development
devel::lang:c-sharp - C# Development
devel::lang:ecmascript - Ecmascript/JavaScript Development
devel::lang:fortran - Fortran Development
devel::lang:haskell - Haskell Development
devel::lang:java - Java Development
devel::lang:lisp - Lisp Development
devel::lang:lua - Lua Development
devel::lang:ml - ML Development
devel::langbjc - Objective-C Development
devel::langcaml - OCaml Development
devel::langctave - GNU Octave Development
devel::langascal - Pascal Development
devel::langerl - Perl Development
devel::langhp - PHP Development
devel::langike - Pike Development
devel::langosix-shell - POSIX shell
devel::langrolog - Prolog Development
devel::langython - Python Development
devel::lang:r - GNU R Development
devel::lang:ruby - Ruby Development
devel::lang:scheme - Scheme Development
devel::lang:sql - SQL
devel::lang:tcl - Tcl Development
devel::library - Libraries
devel::machinecode - Machine Code
devel::modelling - Modelling
devel:ackaging - Packaging
devel:rettyprint - Prettyprint
devel:rofiler - Profiling
devel::rcs - Revision Control
devel::rpc - RPC
devel::runtime - Runtime Support
devel::testing-qa - Testing and QA
devel::ui-builder - User Interface
devel::web - Web

Accessibility support:

accessibility::input - Input Systems
accessibility:cr - Text Recognition (OCR)
accessibility::screen-magnify - Screen Magnification
accessibility::screen-reader - Screen Reading
accessibility::speech - Speech Synthesis
accessibility::speech-recognition - Speech Recognition

Role in the context of system administration:

admin::accounting - Accounting
admin::automation - Automation and Scheduling
admin::backup - Backup and Restoration
admin::benchmarking - Benchmarking
admin::boot - System Boot
admin::cluster - Clustering
admin::configuring - Configuration Tool
admin::file-distribution - File Distribution
admin::filesystem - Filesystem Tool
admin::forensics - Forensics and Recovery
admin::hardware - Hardware Support
admin::install - System Installation
admin::issuetracker - Issue Tracker
admin::kernel - Kernel or Modules
admin::logging - Logging
admin::login - Login
admin::monitoring - Monitoring
admin:ackage-management - Package Management
admin:ower-management - Power Management
admin::recovery - Data Recovery
admin::user-management - User Management
admin::virtualization - Virtualization


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>
 
Old 02-27-2009, 11:12 AM
Mark Brown
 
Default Making some tags mandatory

On Fri, Feb 27, 2009 at 11:48:30AM +0000, Enrico Zini wrote:

> - For packages with no tags in the control file, take the tags from the
> review tag set as we have now

Are packages supposed to do this? If they are it'd probably be worth
announcing more generally to let people know it's OK to do this.

--
"You grabbed my hand and we fell into it, like a daydream - or a fever."


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-27-2009, 09:21 PM
Enrico Zini
 
Default Making some tags mandatory

On Fri, Feb 27, 2009 at 12:12:48PM +0000, Mark Brown wrote:
> On Fri, Feb 27, 2009 at 11:48:30AM +0000, Enrico Zini wrote:
>
> > - For packages with no tags in the control file, take the tags from the
> > review tag set as we have now
>
> Are packages supposed to do this? If they are it'd probably be worth
> announcing more generally to let people know it's OK to do this.

Please note that it is a proposal. At the moment, the main and the
suggested way to tag package is to go to
http://debtags.alioth.debian.org/todo.html or
http://debtags.alioth.debian.org/edit.html and follow the instructions.


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>
 
Old 02-27-2009, 11:30 PM
Ben Finney
 
Default Making some tags mandatory

Enrico Zini <enrico@enricozini.org> writes:

> At the end of this mail is the list that I propose: it's 138 of
> them, but grouped as they are, they should be quite clear to grasp.
> I consider these groups of tags (debtags calls them facets) to be
> mature and uncontroversial enough to be made official and to ask
> maintaners to take care of them.

I like this proposal, thank you for presenting it.

> * The list
>
> Role of the package in the archive (mandatory for all packages):
>
> role::app-data - Application Data
> role::data - Standalone Data
> role::debug-symbols - Debugging symbols
> role::devel-lib - Development Library
> role::documentation - Documentation
> role::dummy - Dummy Package
> role::kernel - Kernel and Modules
> role::metapackage - Metapackage
> role:lugin - Plugin
> role:rogram - Program
> role::shared-lib - Shared Library
> role::source - Source Code
>
> Language that the package is implemented in (mandatory for all
> packages mostly consisting of software):

Arguably, *all* digital information is software (as contrasted with
the hardware that contains it), so every Debian package consists
entirely of software.

Whether or not you agree with that, it would be best for this proposal
if the set of packages for which “foo is mandatory” were clearly
deliniated:

Language(s) that the package is implemented in. Mandatory for all
packages mostly consisting of programs or program components
(role::debug-symbols, role::devel-lib, role::kernel, role:lugin,
role:rogram, role::shared-lib, role::source).

That is, the determination of whether an ‘implemented-in’ facet is
mandatory is whether the package has one of the enumerated tags from
the ‘role’ facet. (If that set of tags is wrong, feel free to correct
it of course.)

> User interface (mandatory for all packages mostly consisting of
> software):

Likewise:

User interface(s) for the programs in the package. Mandatory for
all packages mostly consisting of executable programs
(role:lugin, role:rogram).

--
“I do not believe in immortality of the individual, and I |
` consider ethics to be an exclusively human concern with no |
_o__) superhuman authority behind it.” —Albert Einstein, letter, 1953 |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-28-2009, 06:26 AM
Josselin Mouette
 
Default Making some tags mandatory

Le vendredi 27 février 2009 * 11:48 +0000, Enrico Zini a écrit :
> uitoolkit::athena - Athena Widgets
> uitoolkit::fltk - FLTK
> uitoolkit::glut - GLUT
> uitoolkit::gnustep - GNUstep
> uitoolkit::gtk - GTK
> uitoolkit::motif - Lesstif/Motif
> uitoolkit::ncurses - Ncurses TUI
> uitoolkit::qt - Qt
> uitoolkit::sdl - SDL
> uitoolkit::tk - Tk
> uitoolkit::wxwidgets - wxWidgets
> uitoolkit::xlib - X library

You can add uitoolkit::clutter, it’s going to be more widespread in the
near future.

Cheers,
--
.'`. Debian 5.0 "Lenny" has been released!
: :' :
`. `' Last night, Darth Vader came down from planet Vulcan and told
`- me that if you don't install Lenny, he'd melt your brain.
 
Old 02-28-2009, 04:11 PM
Jrg Sommer
 
Default Making some tags mandatory

Hi Enrico,

Enrico Zini <enrico@enricozini.org> wrote:
> * The proposal
>
> At the end of this mail is the list that I propose: it's 138 of them,
> but grouped as they are, they should be quite clear to grasp. I
> consider these groups of tags (debtags calls them facets) to be mature
> and uncontroversial enough to be made official and to ask maintaners to
> take care of them.

Which tag should I choose if no tag matches? Should you provide a tag
:ther for each facet?

Bye, Jrg.
--
Freiheit heit, die Wahl zu haben, wessen Sklave man ist.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-28-2009, 09:18 PM
Ben Finney
 
Default Making some tags mandatory

Jörg Sommer <joerg@alea.gnuu.de> writes:

> Which tag should I choose if no tag matches?

If no existing tag is appropriate, then either the facet does not
apply to that package, or a new tag is required for that facet.

> Should you provide a tag :ther for each facet?

That suggests that the package is properly tagged that way; I don't
think that's true for any package. Instead, if a package needs a tag
that does not yet exist, that tag should be created.

The editing interface for debtags uses ‘foofacet::TODO’ (with the
description “Need an extra tag”) for this purpose. A package so
tagged needs a new tag in ‘foofacet’ to be created.

I don't know the mechanism by which ‘foofacet::TODO’ triggers creation
of a new tag, but the meaning is clearer at least.

--
“Progress might have been all right once, but it's gone on too |
` long.” —Ogden Nash |
_o__) |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-01-2009, 12:42 AM
Carsten Hey
 
Default Making some tags mandatory

Deborphan needs a way to detect shared libraries like the ones currently
in section libs and distinguish them from packages which are technically
shared libraries but can not assumed to be orphaned when no other
package depends on them. The obvious examples for such packages are
modules (role::module?), e.g. those used by pam, apache or roxen.
Examples for less known module (or is role::backend better in this
case?) packages include libdspam7-drv-*.

I'm not sure if there are other, non-module shared library packages that
can not be removed safely. Someone who knows how to use tags should be
able to go through a list of packages which are not in section libs or
oldlibs and tagged role::shared-lib to find out whether additional tags
might be needed or if the remaining packages are just placed in the
wrong section.


On Fri, Feb 27, 2009 at 11:48:30AM +0000, Enrico Zini wrote:
> role::shared-lib - Shared Library

This tag alone is not sufficient:

$ apt-cache show libapache2-mod-mono | grep -o role::shared-lib
role::shared-lib

$ apt-cache show libpam-runtime | grep -o role::shared-lib
role::shared-lib


Regards
Carsten


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-01-2009, 12:01 PM
Ben Hutchings
 
Default Making some tags mandatory

On Sun, 2009-03-01 at 02:42 +0100, Carsten Hey wrote:
> Deborphan needs a way to detect shared libraries like the ones currently
> in section libs and distinguish them from packages which are technically
> shared libraries but can not assumed to be orphaned when no other
> package depends on them.
[...]

There is already a role:lugin which should apply to PAM modules.

Ben.
 
Old 03-01-2009, 01:59 PM
Carsten Hey
 
Default Making some tags mandatory

On Sun, Mar 01, 2009 at 01:01:49PM +0000, Ben Hutchings wrote:
> On Sun, 2009-03-01 at 02:42 +0100, Carsten Hey wrote:
> > Deborphan needs a way to detect shared libraries ...
> [...]
>
> There is already a role:lugin which should apply to PAM modules.

role:lugin seems to fit. How do we ensure that all PAM, Apache, Roxen
modules, all DSPAM backends and so on must be tagged role:lugin? Is
there some kind of debtag policy where such things can be specified?

There are other possibilities to address this issue, either
section::{libs,oldlibs,perl,...} to store the old section or a special
tag that marks the package as safely removable, for example
sepecial::safely-removable or the existing special::auto-inst-parts.
The latter is currently only partly useful for deborphan since only very
few libraries are marked with this tag:

$ grep-debtags -sPackage -FTag special::auto-inst-parts | grep '^Package: lib' | grep -vEc 'common$|data$'
17

Are there any plans to either tag all safely removable shared libraries
with special::auto-inst-parts or remove this tag from the ones that
already got it?

I guess all tags will be included in /var/lib/dpkg/status before
sections will be removed from Debian, is this correct?


Carsten


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 01:06 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org