| 1 |
Hello, |
| 2 |
|
| 3 |
On Sunday 26 of June 2011 09:02:57 Ciaran McCreesh wrote: |
| 4 |
> Here's a completely different way of doing tags: |
| 5 |
|
| 6 |
As far as sets are concerned, how about PROPERTIES=set? |
| 7 |
https://bugs.gentoo.org/show_bug.cgi?id=272488 |
| 8 |
|
| 9 |
It's been proposed years ago. Is there a need to reinvent sets format every |
| 10 |
time it's bought up? |
| 11 |
|
| 12 |
> First, standardise sets. We probably want to go with a format along the |
| 13 |
> lines of: |
| 14 |
> |
| 15 |
> eapi = 4 |
| 16 |
> description = Monkeys |
| 17 |
> |
| 18 |
> dev-monkey/howler |
| 19 |
> dev-monkey/spider |
| 20 |
> |
| 21 |
> >=dev-monkey/spanky-2.0 |
| 22 |
> |
| 23 |
> dev-monkey/squirrel |
| 24 |
> |
| 25 |
> where eapi has to be on the first line. |
| 26 |
> |
| 27 |
> Second, make a bunch of sets named kde-tag, editors-tag, xml-tag, |
| 28 |
> monkeys-tag etc. |
| 29 |
|
| 30 |
I see major disadvantage with this approach. It's painful to maintain. |
| 31 |
Imagine hundreds of different tags, with each package having at least two |
| 32 |
tags. You certainly don't expect anyone to be able to maintain that. |
| 33 |
Also those files cannot be generated since there needs to be some original |
| 34 |
source of tags information to generate such 'sets' from. |
| 35 |
|
| 36 |
I don't need to remind one needs to keep those files synchronized with tree |
| 37 |
changes (package renames, removals) while tags in metadata.xml automatically |
| 38 |
ravel with package. |
| 39 |
|
| 40 |
Tag is a property or attribute of package and should be implemented as |
| 41 |
additional package information, metadata.xml is the most natural choice. |
| 42 |
|
| 43 |
> Third, make tools that allow browsing, searching etc able to list |
| 44 |
> things by tag (or sets in general). |
| 45 |
> |
| 46 |
> Advantages: dead easy to implement, backwards compatible, we need sets |
| 47 |
> anyway. |
| 48 |
|
| 49 |
PROPERTIES=set have the same advantages - they can also be pulled within |
| 50 |
dependency tree by other packages. |
| 51 |
|
| 52 |
> Disadvantages: doesn't use some horribly convoluted system of XML, |
| 53 |
> wikis and web 2.0. |
| 54 |
|
| 55 |
Using already proven technologies and tools is barely disadvantage. I think |
| 56 |
last thing we need is yet another obscure format nothing widely usable |
| 57 |
understands. |
| 58 |
|
| 59 |
Sets concept is completely orthogonal to tags concept, please do not mix |
| 60 |
unrelated things. |
| 61 |
|
| 62 |
-- |
| 63 |
regards |
| 64 |
MM |
Archives