public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Maciej Mrozowski <reavertm@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Are tags just sets?
Date: Sun, 26 Jun 2011 17:12:27 +0200	[thread overview]
Message-ID: <201106261712.27665.reavertm@gmail.com> (raw)
In-Reply-To: <20110626080257.12d523ef@googlemail.com>

[-- Attachment #1: Type: Text/Plain, Size: 2102 bytes --]

Hello,

On Sunday 26 of June 2011 09:02:57 Ciaran McCreesh wrote:
> Here's a completely different way of doing tags:

As far as sets are concerned, how about PROPERTIES=set?
https://bugs.gentoo.org/show_bug.cgi?id=272488

It's been proposed years ago. Is there a need to reinvent sets format every 
time it's bought up?

> 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.

I see major disadvantage with this approach. It's painful to maintain.
Imagine hundreds of different tags, with each package having at least two 
tags. You certainly don't expect anyone to be able to maintain that.
Also those files cannot be generated since there needs to be some original 
source of tags information to generate such 'sets' from.

I don't need to remind one needs to keep those files synchronized with tree 
changes (package renames, removals) while tags in metadata.xml automatically 
ravel with package.

Tag is a property or attribute of package and should be implemented as 
additional package information, metadata.xml is the most natural choice.

> Third, make tools that allow browsing, searching etc able to list
> things by tag (or sets in general).
> 
> Advantages: dead easy to implement, backwards compatible, we need sets
> anyway.

PROPERTIES=set have the same advantages - they can also be pulled within 
dependency tree by other packages.

> Disadvantages: doesn't use some horribly convoluted system of XML,
> wikis and web 2.0.

Using already proven technologies and tools is barely disadvantage. I think 
last thing we need is yet another obscure format nothing widely usable 
understands.

Sets concept is completely orthogonal to tags concept, please do not mix 
unrelated things.

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  parent reply	other threads:[~2011-06-26 15:13 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 ` Maciej Mrozowski [this message]
2011-06-26 18:42   ` [gentoo-dev] " 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
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=201106261712.27665.reavertm@gmail.com \
    --to=reavertm@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