1 |
On Mon, 27 Jun 2011 20:21:29 +0200 |
2 |
Maciej Mrozowski <reavertm@×××××.com> wrote: |
3 |
> > The problems with PROPERTIES=set remain exactly the same as they |
4 |
> > were when it was first proposed. |
5 |
> |
6 |
> Which is? |
7 |
> No, "been there, done that, won't work" is not sufficient. Please |
8 |
> elaborate. |
9 |
|
10 |
You can find and read the original discussion as well as I can. No |
11 |
point in going over exactly the same material all over again since the |
12 |
design hasn't been updated since. |
13 |
|
14 |
> > Uh, I don't see how that's in any way difficult to maintain. |
15 |
> |
16 |
> No, it's not difficult, it's pain in ass to keep a hundred files with |
17 |
> a few thousands lines each up2date with tree changes (pkgmove, cvs |
18 |
> remove). Yes, it could be automated by some crafty cvs hook on |
19 |
> server. However cvs hooks should be the last resort and not a tool to |
20 |
> deal with consequences of broken design. |
21 |
|
22 |
If that were true, you'd be doing the same thing for package.mask... |
23 |
*shrug* If you really think it's that bad, though, go with Brian's |
24 |
proposal, and whilst you're at it, make package.mask and all those |
25 |
other profile files that contain long lists of package names be created |
26 |
the same way. |
27 |
|
28 |
> > > Tag is a property or attribute of package |
29 |
> > That one's highly debatable. |
30 |
> |
31 |
> It's not debatable for those familiar with object oriented design |
32 |
> concept. |
33 |
|
34 |
Clearly it is. Have a look at posts in this thread. Some people insist |
35 |
that tags are properties of ebuilds, some that they're properties of |
36 |
packages, some that they're repository-level properties, and some that |
37 |
they're external, user-level properties. |
38 |
|
39 |
For that matter, ebuilds aren't object oriented. |
40 |
|
41 |
> > Good, so you'll be happy going with what Unix has been using for |
42 |
> > decades then. |
43 |
> |
44 |
> Indeed, with sets in bash (ebuild) format. |
45 |
|
46 |
No point, just like there's no point in package.mask being an ebuild. |
47 |
|
48 |
> > Depends upon what you think the "tags concept" is. We've already |
49 |
> > established that everyone has a different idea of what tags are |
50 |
> > anyway. |
51 |
> |
52 |
> I don't know what's everyone's idea behind the tag, I refer to: |
53 |
> |
54 |
> http://en.wikipedia.org/wiki/Tag_(metadata) |
55 |
|
56 |
Sure, and that's sufficiently vague that all sorts of completely |
57 |
different ideas could be called tags. |
58 |
|
59 |
-- |
60 |
Ciaran McCreesh |