From: Brian Harring <ferringb@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Are tags just sets?
Date: Mon, 27 Jun 2011 20:26:29 -0700 [thread overview]
Message-ID: <20110628032629.GA9911@localhost> (raw)
In-Reply-To: <20110626080257.12d523ef@googlemail.com>
On Sun, Jun 26, 2011 at 08:02:57AM +0100, Ciaran McCreesh wrote:
> Here's a completely different way of doing tags:
>
> First, standardise sets. We probably want to go with a format along the
> lines of:
>
> eapi = 4
> description = Monkeys
>
> dev-monkey/howler
> dev-monkey/spider
> >=dev-monkey/spanky-2.0
> dev-monkey/squirrel
>
> where eapi has to be on the first line.
>
> Second, make a bunch of sets named kde-tag, editors-tag, xml-tag,
> monkeys-tag etc.
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.
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. 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.
Roughly, and this is definitely a rough sketch:
<tags>
<atom val=dev-util/diffball>tag1 tag2 tag2 tag3</atom>
<atom val=">=dev-util/diffball-1.0">awesomeness</atom>
</tags>
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.
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.
<proceed w/ xml bashing>
~harring
next prev parent reply other threads:[~2011-06-28 3:27 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-26 7:02 [gentoo-dev] Are tags just sets? Ciaran McCreesh
2011-06-26 8:41 ` Michał Górny
2011-06-26 8:43 ` Ciaran McCreesh
2011-06-26 8:54 ` Michał Górny
2011-06-26 9:00 ` Ciaran McCreesh
2011-06-26 12:48 ` Michał Górny
2011-06-27 5:51 ` Ciaran McCreesh
2011-06-26 11:33 ` Wyatt Epp
2011-06-26 12:17 ` Kent Fredric
2011-06-26 14:40 ` [gentoo-dev] " Duncan
2011-06-26 15:12 ` [gentoo-dev] " Maciej Mrozowski
2011-06-26 18:42 ` Kent Fredric
2011-06-27 5:49 ` Ciaran McCreesh
2011-06-27 18:21 ` Maciej Mrozowski
2011-06-28 6:19 ` Ciaran McCreesh
2011-06-27 20:23 ` Rich Freeman
2011-06-27 21:06 ` Wyatt Epp
2011-06-27 21:23 ` Rich Freeman
2011-06-27 21:39 ` Wyatt Epp
2011-06-28 6:19 ` Ciaran McCreesh
2011-06-28 3:26 ` Brian Harring [this message]
2011-06-28 3:43 ` Kent Fredric
2011-06-28 9:31 ` Brian Harring
2011-06-28 11:53 ` Peter Volkov
2011-06-28 15:33 ` Wyatt Epp
2011-06-28 18:52 ` Maciej Mrozowski
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=20110628032629.GA9911@localhost \
--to=ferringb@gmail.com \
--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