From: Mart Raudsepp <leio@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Category tags on packages (was: new categories:)
Date: Tue, 03 Feb 2009 03:17:42 +0200 [thread overview]
Message-ID: <1233623862.31569.20.camel@localhost> (raw)
In-Reply-To: <200902022310.27612.reavertm@poczta.fm>
[-- Attachment #1: Type: text/plain, Size: 3077 bytes --]
On Mon, 2009-02-02 at 23:10 +0100, Maciej Mrozowski wrote:
> On Monday 02 of February 2009 22:15:53 Luca Barbato wrote:
>
> > not sure how useful could be but could make more sense even if right now
> > kde-base contains everything comes from the main kde distribution.
>
> To be more specific, kde-base contains everything (and only) that is
> distributed as KDE stable release (no extragear included). And it causes
> confusion as when packages are dropped from KDE release schedule (so they
> usually go back to extragear to release when they want), one needs to look to
> new place for them (in kde-misc or somewhere else).
> Actually categories are bad idea imho.
> I was thinking, maybe it would be possible to drop categories completely in
> the future (maybe keeping symlinks for compatibility and to ease migration)
> and to put *all* packages in one directory - that would require making all
> names unique of course.
> "Categorization" could be provided for user/search tools as tag clouds being
> defined in metadata.xml as vector of tag:weight values where tag would be some
> word from defined dictionary (word like "mail" "client" "kde" "dns" or sth)
> and weight - real value [0,1] defining how relevant is that tag.
> For compatibility's sake symlinks could be provided, in.ex. sys-devel/gcc ->
> all/gcc.
> But that's just an off-topic.
I agree that a tag kind of approach would be nice. Someone should
actually do work on it.
Here's a random similar idea that I think might work well as a GLEP
proposition, that I was about to reply to a different subthread before
noticing this post:
Packages metadata.xml can be extended with an unlimited amount of <tag>
elements, whose #text can be a tag string, but one that is limited to a
given list in some other place - to have a list of existing tags and not
just randomly have tags for everything. Make an effort to populate all
packages with sensible tags. Then write tools around it that can show
you all packages with a given tag or tags, what tags exist, etc. Those
will be your new categories that answer the question of "what mail
clients are there" (mail-client tag) or "what mail clients are there
using GTK+, well suited for a GNOME environment" (mail-client and gnome
tags).
Keep categories in place for repository tree sanity (not a huge amount
of directories with all packages being sibling dirs) and easier
implementation of it all. No-one really types in the categories anyway,
and with a tool that deals with the tags, you don't look at the subdirs
either - so categories for the user just become a way to differentiate
packages with the same name for the few cases there are equal names.
However those that prefer the categories approach, can keep using it.
Developers also deal with categories, but that's easy enough to keep
going as is.
Less radical, less controversial, better viability to actually get done.
--
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2009-02-03 1:17 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-01 17:32 [gentoo-dev] new categories: (was: Last Rites: games-puzzle/ksudoku) Norberto Bensa
2009-02-01 18:20 ` AllenJB
2009-02-01 18:58 ` Rémi Cardona
2009-02-03 1:10 ` Mart Raudsepp
2009-02-02 21:15 ` Luca Barbato
2009-02-02 21:41 ` Norberto Bensa
2009-02-02 22:10 ` Maciej Mrozowski
2009-02-03 1:17 ` Mart Raudsepp [this message]
2009-02-03 2:49 ` [gentoo-dev] Category tags on packages (was: new categories:) Nirbheek Chauhan
2009-02-04 10:20 ` Luca Barbato
2009-02-08 17:59 ` Federico Ferri
2009-02-08 18:10 ` Nirbheek Chauhan
2009-02-08 18:11 ` Nirbheek Chauhan
2009-02-08 18:46 ` Tiziano Müller
2009-02-08 18:29 ` Federico Ferri
2009-02-08 19:07 ` Angelo Arrifano
2009-02-08 19:17 ` Rémi Cardona
2009-02-08 22:19 ` [gentoo-dev] " Ryan Hill
2009-02-08 22:34 ` Federico Ferri
2009-02-08 18:51 ` [gentoo-dev] " Tiziano Müller
2009-02-09 22:43 ` Maciej Mrozowski
2009-02-03 7:10 ` [gentoo-dev] new categories: Josh Saddler
2009-02-03 10:47 ` George Shapovalov
2009-02-03 13:34 ` Denis Dupeyron
2009-02-03 19:21 ` [gentoo-dev] " Steve Long
2009-02-03 19:22 ` Steve Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1233623862.31569.20.camel@localhost \
--to=leio@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox