From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from <gentoo-dev+bounces-34175-garchives=archives.gentoo.org@lists.gentoo.org>) id 1LU9v3-0002Bk-Bw for garchives@archives.gentoo.org; Tue, 03 Feb 2009 01:17:41 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 259F6E03F0; Tue, 3 Feb 2009 01:17:40 +0000 (UTC) Received: from smtp-out.neti.ee (smtp-out.neti.ee [194.126.126.44]) by pigeon.gentoo.org (Postfix) with ESMTP id C8C4FE03F0 for <gentoo-dev@lists.gentoo.org>; Tue, 3 Feb 2009 01:17:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by MXR-13.estpak.ee (Postfix) with ESMTP id ADD5F4D9B5 for <gentoo-dev@lists.gentoo.org>; Tue, 3 Feb 2009 03:17:38 +0200 (EET) X-Virus-Scanned: amavisd-new at !change-mydomain-variable!.example.com Received: from smtp-out.neti.ee ([127.0.0.1]) by localhost (MXR-1.estpak.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjS91jxy1MTE for <gentoo-dev@lists.gentoo.org>; Tue, 3 Feb 2009 03:17:38 +0200 (EET) Received: from Relayhost1.neti.ee (Relayhost1 [88.196.174.141]) by MXR-13.estpak.ee (Postfix) with ESMTP id 54B194CD83 for <gentoo-dev@lists.gentoo.org>; Tue, 3 Feb 2009 03:17:38 +0200 (EET) X-SMTP-Auth-NETI-Businesmail: no Subject: [gentoo-dev] Category tags on packages (was: new categories:) From: Mart Raudsepp <leio@gentoo.org> To: gentoo-dev@lists.gentoo.org In-Reply-To: <200902022310.27612.reavertm@poczta.fm> References: <84250c9c0902010932m539beba1v19fac18fde4569d9@mail.gmail.com> <49876289.20306@gentoo.org> <200902022310.27612.reavertm@poczta.fm> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-P3kbWK9p1R1pAcxOXGly" Date: Tue, 03 Feb 2009 03:17:42 +0200 Message-Id: <1233623862.31569.20.camel@localhost> Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 X-Archives-Salt: 0b2a3a4e-1aef-4261-b192-d7608913e1d0 X-Archives-Hash: 49d13fd1a36cdf2464df7e99ab05b44c --=-P3kbWK9p1R1pAcxOXGly Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 2009-02-02 at 23:10 +0100, Maciej Mrozowski wrote: > On Monday 02 of February 2009 22:15:53 Luca Barbato wrote: >=20 > > not sure how useful could be but could make more sense even if right no= w > > kde-base contains everything comes from the main kde distribution. >=20 > To be more specific, kde-base contains everything (and only) that is=20 > distributed as KDE stable release (no extragear included). And it causes=20 > confusion as when packages are dropped from KDE release schedule (so they= =20 > usually go back to extragear to release when they want), one needs to loo= k to=20 > 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=20 > the future (maybe keeping symlinks for compatibility and to ease migratio= n)=20 > and to put *all* packages in one directory - that would require making al= l=20 > names unique of course. > "Categorization" could be provided for user/search tools as tag clouds be= ing=20 > defined in metadata.xml as vector of tag:weight values where tag would be= some=20 > word from defined dictionary (word like "mail" "client" "kde" "dns" or st= h)=20 > 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= ->=20 > all/gcc. > But that's just an off-topic. =EF=BB=BF 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. --=20 Mart Raudsepp Gentoo Developer Mail: leio@gentoo.org Weblog: http://planet.gentoo.org/developers/leio --=-P3kbWK9p1R1pAcxOXGly Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (GNU/Linux) iEYEABECAAYFAkmHmzYACgkQkeYb6olFHJdNaACgrCmFV/aMcgDTq1xj7mepYN9B GPYAn3hxpLpZn8LF0cHvIP7y6XrXAXv8 =WBGn -----END PGP SIGNATURE----- --=-P3kbWK9p1R1pAcxOXGly--