From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Qbdh7-0004yY-2w for garchives@archives.gentoo.org; Tue, 28 Jun 2011 19:11:33 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 30F021C016; Tue, 28 Jun 2011 19:08:25 +0000 (UTC) Received: from mail-fx0-f52.google.com (mail-fx0-f52.google.com [209.85.161.52]) by pigeon.gentoo.org (Postfix) with ESMTP id 353941C024 for ; Tue, 28 Jun 2011 18:53:16 +0000 (UTC) Received: by fxd18 with SMTP id 18so505994fxd.11 for ; Tue, 28 Jun 2011 11:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to :disposition-notification-to:mime-version:content-type :content-transfer-encoding:message-id; bh=WcY3veWxkeQApkVhkyULrd8bOcV4NDZrOYjD+tXUALY=; b=ZgsokuqWGxxr7RAo0BqTC0dZHhAWL6hbju4Pc4gFO+Hjwh1l14Uw0U8Wl6AWh/UxMt 2EZoBvCR+aEbCEBVkbY1QQDuH6d2tINwZxDxqB5nWSui1QIBf0tA+C4YoSAsK5YHdEth JsgH3bUQkEK4fPn9FuSlP8BqmLFalp/kM+LfU= Received: by 10.223.71.194 with SMTP id i2mr477445faj.42.1309287194997; Tue, 28 Jun 2011 11:53:14 -0700 (PDT) Received: from lebrodyl.localnet (89-78-62-193.dynamic.chello.pl [89.78.62.193]) by mx.google.com with ESMTPS id o23sm313336faa.9.2011.06.28.11.53.13 (version=SSLv3 cipher=OTHER); Tue, 28 Jun 2011 11:53:13 -0700 (PDT) From: Maciej Mrozowski To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Are tags just sets? Date: Tue, 28 Jun 2011 20:52:39 +0200 User-Agent: KMail/1.13.7 (Linux/3.0.0-rc4-wl; KDE/4.6.4; x86_64; ; ) References: <20110626080257.12d523ef@googlemail.com> <20110628032629.GA9911@localhost> In-Reply-To: <20110628032629.GA9911@localhost> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1473873.ZRFFKdIXXc"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201106282052.39321.reavertm@gmail.com> X-Archives-Salt: X-Archives-Hash: e89fd2dcd76c94586143b85dc4c2c4a9 --nextPart1473873.ZRFFKdIXXc Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tuesday 28 of June 2011 05:26:29 Brian Harring wrote: > On Sun, Jun 26, 2011 at 08:02:57AM +0100, Ciaran McCreesh wrote: > > Here's a completely different way of doing tags: > >=20 > > First, standardise sets. We probably want to go with a format along the > >=20 > > lines of: > > eapi =3D 4 > > description =3D Monkeys > > =20 > > dev-monkey/howler > > dev-monkey/spider > > =20 > > >=3Ddev-monkey/spanky-2.0 > > =20 > > dev-monkey/squirrel > >=20 > > where eapi has to be on the first line. > >=20 > > Second, make a bunch of sets named kde-tag, editors-tag, xml-tag, > > monkeys-tag etc. >=20 > This is a bit inverted- tagging is fundamentally pkg specific. If we > did as you proposed and I wanted to find out all tags/descriptions for > a pkg, the PM would have to scan every tags file there. >=20 > Additionally, as others have indicated, it sucks have this data tucked > away in another chunk of the tree, away from where the package data > actually is (in cat/pkg/*). >=20 > > Advantages: dead easy to implement, backwards compatible, we need sets > > anyway. > >=20 > > Disadvantages: doesn't use some horribly convoluted system of XML, > > wikis and web 2.0. >=20 > Counter proposal; use what you're proposing as a cache. metadata.xml > is the proper place for this- we store use.local data there for > example, and cache the results of it in profiles/use.local.desc. Via > this vcs concerns are addressed, data locality is preserved, and > multiple modes of lookup are sanely supported. >=20 > Roughly, and this is definitely a rough sketch: >=20 > > tag1 tag2 tag2 tag3 > =3Ddev-util/diffball-1.0">awesomeness > >=20 > From there, jammed into profiles, a master description list in 'tag: > description' style format. Identifying the eapi is easy enough- just > inspect the atom's that wind up in the tags list. Easy enough. >=20 > Either way... thing everyone admits the current tree format has it's > flaws; strikes me it's better to fit to the standards/conventions of > the repo format as it is now. >=20 > > ~harring Of course, nobody said metadata.xml would be the place that's to be=20 immediately accessed by search tools. But as a data definition is concerned= ,=20 metadata.xml is the right place for tags, not some obscure 'package.mask'- style flat file. Whether this information is to be processed for easier usage - by generatin= g=20 flat file with "cat/pkg tag1 tag2 ..." in each line for instance - is=20 different story and nice to have probably. @Ciaran profiles/package.mask is quite convenient being flat file (although=20 package.mask.d seems nicer, different story) as masking/unmasking groups of= =20 packages (KDE releases come to my mind) is a common use case. Sure, it would benefit from auto-updating (pkgmove mostly as package.mask=20 editing is otherwise closely tied to package removals anyway). =2D-=20 regards MM --nextPart1473873.ZRFFKdIXXc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEABECAAYFAk4KIvcACgkQFuHa/bHpVdvFxQCfY8fuxb+n8imK8ibpODyJ9hCP EJAAoLRGmsDAGFvvRt/ucodfLX0moFNv =hWd4 -----END PGP SIGNATURE----- --nextPart1473873.ZRFFKdIXXc--