On Mon, Jun 27, 2011 at 16:23, Rich Freeman <ri...@gentoo.org> wrote:
> I too feel that tags should be distinct from sets, for a bunch of reasons.
>
> Sets should really be something carefully controlled by the
> repository. While I'm fine with having tags in the repository also,
> there is talk about giving users ways of supplying them as well.
>
Too late; /etc/portage/sets/
> Sets are generally used to tell the package manager to do something
> with a lot of packages at once. I'm not sure there is much of a need
> to do this with tags, at least not in most of the use cases that have
> been suggested.
>
At the moment, yes, that's very true. But that's a matter of lacking
tools, more than a necessarily orthogonal concept. If you look at
sets (or categories), you find they describe attributes of packages.
For example, @world is "everything the user has merged". The kde
overlay provides things like @kde-live, "kde packages built from
subversion" (it's more specific than ${PN} in this case, but generally
won't need to be). I don't think anyone here believes this feature
exists without some tool support to glue it together.
> Maybe if we define multiple namespaces for tags we could move to using
> tags as dependencies or whatever, and those tags would be distinct and
> much more carefully defined and controlled. However, I think this is
> more far-out and not the immediate goal.
>
I'd say that's rather unnecessary. We should be wary of conflating
all metadata together in our heads: Tags are not a replacement for
structured key-value that we already have. When we talk of tags,
we're talking about general purpose semantic descriptors that are only
loosely structured and benefit from emergent community standards. We
already have the things that benefit from rigid definition.
> Sets might work, but they seem a bit like a hack...
>
Oh, absolutely. But nearly anything is better than the current state
of affairs; if it falls apart, we find a different way.
