1 |
On Monday 27 of June 2011 07:49:24 Ciaran McCreesh wrote: |
2 |
> On Sun, 26 Jun 2011 17:12:27 +0200 |
3 |
|
4 |
> Maciej Mrozowski <reavertm@×××××.com> wrote: |
5 |
> > On Sunday 26 of June 2011 09:02:57 Ciaran McCreesh wrote: |
6 |
> > > Here's a completely different way of doing tags: |
7 |
> > As far as sets are concerned, how about PROPERTIES=set? |
8 |
> > https://bugs.gentoo.org/show_bug.cgi?id=272488 |
9 |
|
10 |
> > It's been proposed years ago. Is there a need to reinvent sets format |
11 |
> > every time it's bought up? |
12 |
|
13 |
> The problems with PROPERTIES=set remain exactly the same as they were |
14 |
> when it was first proposed. |
15 |
|
16 |
Which is? |
17 |
No, "been there, done that, won't work" is not sufficient. Please elaborate. |
18 |
|
19 |
> > I see major disadvantage with this approach. It's painful to maintain. |
20 |
> > Imagine hundreds of different tags, with each package having at least |
21 |
> > two tags. You certainly don't expect anyone to be able to maintain |
22 |
> > that. |
23 |
|
24 |
> Uh, I don't see how that's in any way difficult to maintain. |
25 |
|
26 |
No, it's not difficult, it's pain in ass to keep a hundred files with a few |
27 |
thousands lines each up2date with tree changes (pkgmove, cvs remove). Yes, it |
28 |
could be automated by some crafty cvs hook on server. However cvs hooks should |
29 |
be the last resort and not a tool to deal with consequences of broken design. |
30 |
|
31 |
> > Tag is a property or attribute of package |
32 |
> That one's highly debatable. |
33 |
|
34 |
It's not debatable for those familiar with object oriented design concept. |
35 |
It may be debatable for database designers what's the best way to implement |
36 |
many to many association because they have means to auto-update referenced |
37 |
keys - we don't have those means so proposal to "move tags to separate table" |
38 |
isn't practical. |
39 |
|
40 |
> > PROPERTIES=set have the same advantages - they can also be pulled |
41 |
> > within dependency tree by other packages. |
42 |
|
43 |
> Yes, but PROPERTIES=set has all of the problems it had when it was |
44 |
> first proposed, and is the wrong way to implement sets. |
45 |
|
46 |
> > > Disadvantages: doesn't use some horribly convoluted system of XML, |
47 |
> > > wikis and web 2.0. |
48 |
|
49 |
> > Using already proven technologies and tools is barely disadvantage. I |
50 |
> > think last thing we need is yet another obscure format nothing widely |
51 |
> > usable understands. |
52 |
|
53 |
> Good, so you'll be happy going with what Unix has been using for |
54 |
> decades then. |
55 |
|
56 |
Indeed, with sets in bash (ebuild) format. |
57 |
|
58 |
> > Sets concept is completely orthogonal to tags concept, please do not |
59 |
> > mix unrelated things. |
60 |
|
61 |
> Depends upon what you think the "tags concept" is. We've already |
62 |
> established that everyone has a different idea of what tags are anyway. |
63 |
|
64 |
I don't know what's everyone's idea behind the tag, I refer to: |
65 |
|
66 |
http://en.wikipedia.org/wiki/Tag_(metadata) |
67 |
|
68 |
-- |
69 |
regards |
70 |
MM |