On Monday 27 of June 2011 07:49:24 Ciaran McCreesh wrote: > On Sun, 26 Jun 2011 17:12:27 +0200
> Maciej Mrozowski <reave...@gmail.com> wrote: > > 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? > The problems with PROPERTIES=set remain exactly the same as they were > when it was first proposed. Which is? No, "been there, done that, won't work" is not sufficient. Please elaborate. > > 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. > Uh, I don't see how that's in any way difficult to maintain. No, it's not difficult, it's pain in ass to keep a hundred files with a few thousands lines each up2date with tree changes (pkgmove, cvs remove). Yes, it could be automated by some crafty cvs hook on server. However cvs hooks should be the last resort and not a tool to deal with consequences of broken design. > > Tag is a property or attribute of package > That one's highly debatable. It's not debatable for those familiar with object oriented design concept. It may be debatable for database designers what's the best way to implement many to many association because they have means to auto-update referenced keys - we don't have those means so proposal to "move tags to separate table" isn't practical. > > PROPERTIES=set have the same advantages - they can also be pulled > > within dependency tree by other packages. > Yes, but PROPERTIES=set has all of the problems it had when it was > first proposed, and is the wrong way to implement sets. > > > 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. > Good, so you'll be happy going with what Unix has been using for > decades then. Indeed, with sets in bash (ebuild) format. > > Sets concept is completely orthogonal to tags concept, please do not > > mix unrelated things. > Depends upon what you think the "tags concept" is. We've already > established that everyone has a different idea of what tags are anyway. I don't know what's everyone's idea behind the tag, I refer to: http://en.wikipedia.org/wiki/Tag_(metadata) -- regards MM
signature.asc
Description: This is a digitally signed message part.
