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 1QbPDS-0001uF-Q3 for garchives@archives.gentoo.org; Tue, 28 Jun 2011 03:43:59 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8F4631C021; Tue, 28 Jun 2011 03:43:49 +0000 (UTC) Received: from mail-ww0-f53.google.com (mail-ww0-f53.google.com [74.125.82.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 6A5451C003 for ; Tue, 28 Jun 2011 03:43:22 +0000 (UTC) Received: by wwf26 with SMTP id 26so4676080wwf.10 for ; Mon, 27 Jun 2011 20:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=DWR+1g44HW75QkkHcoFs6V6u7oGZyWLvMeepARoe00M=; b=twMCCn8PERUMQX7i4P+cIwU4sJNWURWKYplyvblv6Iv+6gVgTonCLBzNiI6PODxmAc GgeN4pGxeOVc+DF0gsQVLU84+HGG82TwddwlK4xmOh6389MsYrCabyb4M+jJBYJmZ3nu z7zNdErNEmywi/posXgKRdZsFknvOjJFKk0ok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=RSFIAIYRv0yJJERgnF/GVg7aZQXJvq3evo4KU0ZO8i/iTd81R3s2vqnfJh16snvlb8 dG7Lx/30ONlsnxchQBwfiEPEb28QF68sTGfk37UkxFMpjUvafp0IWUOaRlKX22vKvOJk XS7wpVEbdR9rupLb0st5TxPPWEIe/GMYMlNHE= 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 Received: by 10.216.68.203 with SMTP id l53mr5832936wed.84.1309232601613; Mon, 27 Jun 2011 20:43:21 -0700 (PDT) Received: by 10.216.36.149 with HTTP; Mon, 27 Jun 2011 20:43:21 -0700 (PDT) In-Reply-To: <20110628032629.GA9911@localhost> References: <20110626080257.12d523ef@googlemail.com> <20110628032629.GA9911@localhost> Date: Tue, 28 Jun 2011 15:43:21 +1200 Message-ID: Subject: Re: [gentoo-dev] Are tags just sets? From: Kent Fredric To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: eff4a656ef2ed2a6f636bda8a77e9d1d On 28 June 2011 15:26, Brian Harring wrote: > This is a bit inverted- tagging is fundamentally pkg specific. =C2=A0If w= e > 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. > > 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/*). > >> Advantages: dead easy to implement, backwards compatible, we need sets >> anyway. >> >> Disadvantages: doesn't use some horribly convoluted system of XML, >> wikis and web 2.0. > > Counter proposal; use what you're proposing as a cache. =C2=A0metadata.xm= l > 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. =C2=A0Vi= a > this vcs concerns are addressed, data locality is preserved, and > multiple modes of lookup are sanely supported. > > Roughly, and this is definitely a rough sketch: > > > =C2=A0tag1 tag2 tag2 tag3 > =C2=A0=3Ddev-util/diffball-1.0">awesomeness > > > From there, jammed into profiles, a master description list in 'tag: > description' style format. =C2=A0Identifying the eapi is easy enough- jus= t > inspect the atom's that wind up in the tags list. =C2=A0Easy enough. > > 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. > > > ~harring > > I agree whole heartedly, I do, really. Ultimately the best design will involve: A. Storing tag data in metadata.xml ( package -> tag association ) B. Developing a tool that aggregates the contents of metadata.xml to produce a cache for the data going the other way ( tag -> package ) People searching for packages that match a tag will thusly be able to read this cached data ( Our primary use case ) and people who want to know what tags a specific package have will read/augment metadata.xml I Believe both these parts are required for the design to be successful. However, both parts have a bit of bike-shedding involved in them, part A of the system requires changes to exisiting structures, and part A requires bike shedding about part B's format. For the sake of simplicity, I'm ( and I believe others ) are simply suggesting we develop part B first. Yes, the initial complications in creating the tag indexes will be somewhat large, but it does mean we can create an early proof of concept that implements a somewhat "usable" tag-search for users without having to really touch portage itself. Once we get that part sorted out and agree upon the general format and requirements of this index/cache, we can then decide how we'll fit it in to metadata.xml --=20 Kent perl -e=C2=A0 "print substr( \"edrgmaM=C2=A0 SPA NOcomil.ic\\@tfrken\", \$_= * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz