|
Home > Archive > Debian Developers > September 2004 > Do we need better documentation about our subsections?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Do we need better documentation about our subsections?
|
|
| Gustavo Franco 2004-09-23, 5:55 pm |
| I was reading the debian-policy searching for detailed instructions on
how to choose the best subsection to put a package, is it documented
anywhere ? The "Subsections"[0] contains:
[...]
"The Debian archive maintainers provide the authoritative list of
subsections. At present, they are: admin, base, comm, contrib, devel,
doc, editors, electronics, embedded, games, gnome, graphics, hamradio,
interpreters, kde, libs, libdevel, mail, math, misc, net, news,
non-US, non-free, oldlibs, otherosfs, perl, python, science, shells,
sound, tex, text, utils, web, x11."
[...]
If i want to package 'foobar', a math program, written in Python that
uses gtk+ bindings.What's the right subsection? math, python, gnome or
x11 ? I guess that the usual way is search for a similar package and
use the same subsection.Is it really right?
FYI, the maintainers guide[1] contains this information about subsections:
"As you may have noticed, Debian is divided in sections: main (the
free software), non-free (the not really free software) and contrib
(free software that depends on non-free software). Under those, there
are logical subsections that describe in short what packages are in.
So we have `admin' for administrator-only programs, `base' for the
basic tools, `devel' for programmer tools, `doc' for documentation,
`libs' for libraries, `mail' for e-mail readers and daemons, `net' for
network apps and daemons, `x11' for X11 programs that don't fit
anywhere else, and many more."
I know that ftpmasters can change a package with a wrong subsection,
what are their guidelines to do it?
[0] = http://www.debian.org/doc/debian-po...l#s-subsections
[1] = http://www.debian.org/doc/maint-gui....html#s-control
Thanks,
Gustavo Franco -- <stratus@acm.org>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thaddeus H. Black 2004-09-23, 8:48 pm |
| Debian's muscular horde of binary packages
overran the beleaguered archive subsection
system years ago. Help is on the way. See
debtags [1] and debram.
--
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, t@b-tk.org
1. http://debtags.alioth.debian.org/
| |
| Remi Vanicat 2004-09-24, 2:50 am |
| On Thu, 23 Sep 2004 18:23:15 -0300, Gustavo Franco
<gustavorfranco@gmail.com> wrote:
> I was reading the debian-policy searching for detailed instructions on
> how to choose the best subsection to put a package, is it documented
> anywhere ? The "Subsections"[0] contains:
>
> [...]
>
> "The Debian archive maintainers provide the authoritative list of
> subsections. At present, they are: admin, base, comm, contrib, devel,
> doc, editors, electronics, embedded, games, gnome, graphics, hamradio,
> interpreters, kde, libs, libdevel, mail, math, misc, net, news,
> non-US, non-free, oldlibs, otherosfs, perl, python, science, shells,
> sound, tex, text, utils, web, x11."
>
> [...]
>
> If i want to package 'foobar', a math program, written in Python that
> uses gtk+ bindings.What's the right subsection? math, python, gnome or
> x11 ? I guess that the usual way is search for a similar package and
> use the same subsection.Is it really right?
Does user that need the functionality of foobar will searchfor a x11,
a python, a gnome or a math program ? Probably a math one, so I will
put it there. I would use the Python section for program that are used
for developpement of Python program, gnome for program that are realy
gnome specific (like applet for example) and x11 for program I have no
other section to put them in. Of course this only my guideline.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Gustavo Franco 2004-09-24, 5:52 pm |
| Hi Thaddeus,
I know debtags and Enrico, but will debtags replace our current
subsections after sarge ? Was it discussed before? Are you needing
help?
On Fri, 24 Sep 2004 00:35:26 +0000, Thaddeus H. Black <t@b-tk.org> wrote:
> Debian's muscular horde of binary packages
> overran the beleaguered archive subsection
> system years ago. Help is on the way. See
> debtags [1] and debram.
>
> [...]
>
> 1. http://debtags.alioth.debian.org/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Enrico Zini 2004-09-25, 5:55 pm |
| On Sat, Sep 25, 2004 at 05:16:51PM +0000, Thaddeus H. Black wrote:
(thread back to the list with author's permission)
>
> Put simply, for several months after sarge
> freezes, I will be working on finishing and
> checking the tagging of sarge's packages. But
> simultaneously also beginning at freeze time,
> new packages for sarge+1 will begin to flow into
> sid at a rate of about 100 binary packages per
> week. I will not be able both to finish the old
> and to keep up with the new at the same time.
>
> Gustavo, we need help tagging sarge+1 packages
> for debtags as they come in. If this were done,
> then when the sarge tags are fully ready, the
> tags base would be immediately up to date.
> Immediate help in this would thus be very much
> appreciated. If you would help, please begin
> preparing your scripts now, because the
> opportunity to act begins the day sarge freezes.
> As far as I know, no one else is ready to act on
> this, so this would be your project.
Yes, there should be more tagging efforts. I have some explanation
about why this doesn't happen:
1. The interfaces to do that are still crappy
(debtags-edit tries to help, but isn't exciting either)
2. Facets and tags are not documented
athough they may be fairly intuitive, there's not much documentation
on how to really do the tagging yet. Although per-facet and per-tag
documentation could already be written, more general documentation
suffers from the fact that:
3. The set of available tags is in continuous refinement
and I feel like we should live with it, as our way of describing
packages should be able to evolve as packages evolve, and as our
understanding of packages evolve.
Ironically, our understanding of packages evolve while we describe
them, so this sounds like a never-ending iterative process.
3. Debtags has no official hat
since I would always like things to get better before an official
launch, I never make an official launch 
It would be nice to at least have a mention about debtags, if still
as an ongoing development project, together with every mention of
subsections (at least, bug 144046 has officially been reassigned to
debtags, so it seems to be our job after all)
4. Package Tags are not yet really in use
and this should change fairly soon, as work is underway to
debtags-enable various package managers
> In my view, that is the highest-priority task,
Yes, it's very important, as it would allow the tag set to expand with
knowledge that is not just mainly mine and Erich's. That would also
mean having more people messing with the tag vocabulary, and more brains
thinking about it.
> but if it did not suit you then here are several
> others our leader Enrico has suggested.
I'll comment on these, possibly giving status updates:
> * Design how to distribute localized
> translations of tag names and descriptions
Help would be so much appreciated. We have had suggestions on how to do
it (convert the vocabulary to .po files to allow translators to use the
existing tools), however I still haven't had time to implement i18n into
the library, and I'd so much appreciate help in that.
> * Design automatic methods to infer tags from
> existing package data; for example, Javier
> Fernández-Sanguino Peña suggested the use of
> TFIDF techniques to extract keywords from
> package descriptions
I started an autodebtag project to create software to infer tags from
existing package data. You can find it at:
svn://svn.debian.org/debtags/autodebtag
This time it's in PERL and not on C++, and so maybe more people would
like to lay their hands on it. That would really need more brains and
fantasy. That'd also be the place to do some TFIDF computations, if
someone wants to implement it.
Curious people are welcome to contact me, send patches, get added to the
project.
> * Find a good way to maintain the central
> Debian tag vocabulary (technical
> infrastructure, people in charge of it)
Here is Erich's domain; unfortunately, he's very busy. He'll probably
put some or all of the server infrastructure on subversion soon, so
there will probably be possibilities to help there as well.
> * Discuss the idea of "Adopting" tags, that is
> having people who take care of the
> correctness of the list of packages
> associated to a given tag (which another
> point of view compared to checking that all
> tags associated to a package are correct)
> (Suggested by Erich Schubert)
This would be a really effective idea for having quality assurance.
Another powerful way to quality assurance is having package managers
which use tags, so that inconsistencies can be spotted and signaled in
everyday life.
> * Discuss the idea of "Outsourcing" the
> maintenance of some tags: for example the
> Gnome and KDE people could take care of
> maintaining the tag data related to Gnome
> and KDE.
Here the idea of facets helps, as different groups could take care of
facets related to areas they know better. For example, the Agnula
people have volunteered to maintain the "sound" facet.
It is still not clear how to do that, however: should all data be kept
in a central database with different access policies, or should everyone
put its data available and people just add and remove sources from
/etc/debtags/sources.list? Or maybe a mix of both approaches.
And what instruments should be provided to these group of people to
track the facets they chose to maintain?
> * Inclusion of "Tag:" fields in package
> control files
Here I'm unsure if it should be done, as the tag data is updated more
often than the package data, as new facets show up, or some are
reorganized. However, having something like that means reminding debian
developers to tag their new packages, which would be very important: as
you say, if 100 new packages per weeks hit the archive, just tagging
those is a pretty tough job, and it would be extremely handy to have
developers at least provide a first, possibly imperfect categorization.
> I appreciate your interest. I think that we all
> appreciate it. Tagging the archive is a big
> task. Please join our low-volume list
> debtags-devel@lists.alioth.debian.org.
Yes, please everyone interest join, and make questions. I have the
problem that I think a lot and write more code than explanations, so I
get in the situation that I have ideas but people don't know about them,
or people don't know where I'm heading and just wait to see what happens
instead of contributing. Please everyone help me getting things out of
my mind and into the wild, and possibly also getting them done ;-)
Ciao,
Enrico
--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>
| |
| Stefano Zacchiroli 2004-09-26, 5:55 pm |
| On Sun, Sep 26, 2004 at 12:49:13AM +0200, Enrico Zini wrote:
> This would be a really effective idea for having quality assurance.
> Another powerful way to quality assurance is having package managers
> which use tags, so that inconsistencies can be spotted and signaled in
> everyday life.
> Here the idea of facets helps, as different groups could take care of
> facets related to areas they know better. For example, the Agnula
> people have volunteered to maintain the "sound" facet.
In debian we have several sub-communities related to various efforts of
the project. The first ones that comes in to my mind are those involved
in maintaining packages related to a given programming language. Just
looking at the debian maling lists list reveals perl, python, ocaml
communities and many more.
It would be a good idea to "assign" (of course someone needs to
volunteer, but ok ... you get the idea) the maintanance of communities
related tags to the communities themselves.
I volunteer to maintain to maintain the tags related to the ocaml
programming language. (BTW, I already tried twice in the past to mail
the debian-usability project on the subject but I was unable to get my
mail trhu, where those discussion needs now to be carried on?
debtags-devel?)
> Here I'm unsure if it should be done, as the tag data is updated more
> often than the package data, as new facets show up, or some are
> reorganized. However, having something like that means reminding debian
> developers to tag their new packages, which would be very important: as
> you say, if 100 new packages per weeks hit the archive, just tagging
> those is a pretty tough job, and it would be extremely handy to have
> developers at least provide a first, possibly imperfect categorization.
I agree with Enrico here. debtags is a successfull effort in my opinion
exactly because it was set up independently from our central package
database. This permits to "risks" a bit more and doesn't necessarly need
involvement by the people in care of maintaining our core tools which
could be busy in some higher priority goal.
Cheers.
--
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-
| |
| Thaddeus H. Black 2004-09-26, 5:55 pm |
| Having tagged some sixteen thousand Debian binary packages over the past
two years, I should admit that my own experience strongly confirms
Enrico's observation:
> 3. The set of available tags is in continuous refinement
> and I feel like we should live with it, as our way of describing
> packages should be able to evolve as packages evolve, and as our
> understanding of packages evolve.
> Ironically, our understanding of packages evolve while we describe
> them, so this sounds like a never-ending iterative process.
| |
| Enrico Zini 2004-09-26, 5:55 pm |
| On Sun, Sep 26, 2004 at 09:00:25AM +0200, Stefano Zacchiroli wrote:
> I volunteer to maintain to maintain the tags related to the ocaml
> programming language. (BTW, I already tried twice in the past to mail
> the debian-usability project on the subject but I was unable to get my
> mail trhu, where those discussion needs now to be carried on?
> debtags-devel?)
debtags-devel, yes. If you have problems posting there, please don't
hesitate to write me in private and I'll try to solve them.
Thanks for volunteering. You gave me the idea to add a
"Responsible: email@address.org" field to the vocabulary for the facets
or tags which are being taking care by people.
So, it becomes:
Facet: implemented-in
Description: Language that the package is implemented in
[...]
Tag: implemented-in::ocaml
Responsible: zack@debian.org
Description: Ocaml
Facet: langdevel
Description: Language that the package supports development for
[...]
Tag: langdevel::ocaml
Responsible: zack@debian.org
Description: Ocaml Development
If other people are interested in specific fields, please write me.
Some example of facets and tags to tickle the appetite of you all:
(note that facets are entire groups of tags; the complete set can be
downloaded from: http://people.debian.org/~enrico/tags/vocabulary.gz)
Facet: accessibility
Description: Accessibility support provided
Tag: accessibility::input
Description: Alternative input systems
[...]
Tag: accessibility::speech
Description: Speech synthesizers
Tag: accessibility::speech-recognition
Description: Speech Recognition
Facet: admin
Description: Administration and System Maintainance
Tag: culture::afrikaans
Description: Afrikaans localization
Tag: culture::arabic
Description: Arabic localization
[...]
Tag: culture::welsh
Description: Welsh localization
Facet: devel
Description: Software development / programming
Tag: devel::bugtracker
Description: Bug tracking tools
[...]
Tag: devel::ui-builder
Description: User Interface Builder
Facet: field
Description: Special field that the package belongs to
Tag: field::astronomy
Description: Astronomy
[...]
Tag: field::physics
Description: Physics
Facet: game
Description: Games, fun and entertainment
Facet: hardware
Description: Special kinds of hardware that the package supports
Tag: hardware::camera
Description: Digital cameras and webcams
[...]
Tag: hardware::video
Description: Video boards
Facet: ipv6
Description: IPv6 networking
Facet: security
Description: How the package is related to system security
Facet: suite
Description: The package is related to a bigger group of packages
Tag: suite::apache
Description: Apache
[...]
Tag: suite::zope
Description: Z Object Publishing Environment (ZOPE)
The zope (web) publishing platform.
Facet: dbtech
Description: Database related technology
Facet: format
Description: Data format
...and many, many more!
Ciao,
Enrico
--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>
| |
| Enrico Zini 2004-09-26, 5:55 pm |
| On Sun, Sep 26, 2004 at 08:15:40PM +0200, Enrico Zini wrote:
> debtags-devel, yes. If you have problems posting there, please don't
> hesitate to write me in private and I'll try to solve them.
>
> Thanks for volunteering. You gave me the idea to add a
> "Responsible: email@address.org" field to the vocabulary for the facets
> or tags which are being taking care by people.
I forgot some tips for people interested in adopting tags: besides
using debtags-edit to tag and check which packages are tagged with the
various tags, you can also do something like this:
debtags cat | tagcoll reverse | grep '^\(implemented-in\|langdevel\)::ocaml'
Ciao,
Enrico taking advantage of the opportunity for showing off some
commandline debtags trick to the whole developer community
--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>
| |
| Enrico Zini 2004-09-26, 5:55 pm |
| On Sun, Sep 26, 2004 at 08:47:46PM +0200, Enrico Zini wrote:
> debtags cat | tagcoll reverse | grep '^\(implemented-in\|langdevel\)::ocaml'
Or even "debtags grep '(implemented-in::ocaml || langdevel::ocaml)'"
Ciao,
Enrico who had forgot he had implemented something very cool, and now
stops annoying the list ;)
--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>
| |
| Stefano Zacchiroli 2004-09-26, 5:55 pm |
| On Sun, Sep 26, 2004 at 08:15:40PM +0200, Enrico Zini wrote:
> If other people are interested in specific fields, please write me.
> Some example of facets and tags to tickle the appetite of you all:
I don't know at which stage of the tagging initiative you're, but once
you're ready (and please try to minimize perfectionism Enrico :-P) I
think this call for volunteer deserves more relevance than an hidden
post in debian-devel.
Cheers.
--
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-
|
|
|
|
|