On Wed, Aug 20, 2008 at 5:42 PM, Xavier <shiningxc@gmail.com> wrote:
About the feature itself, here is the last thread where it was discussed : http://archlinux.org/pipermail/pacman-dev/2007-June/008555.html I was always divided about it. I understand the point of view "groups are installable, categories are not" However, after having a look at this patch, it seems like it justifies Nagy's opinion even more : http://archlinux.org/pipermail/pacman-dev/2007-June/008565.html This category implementation basically looks like a duplication of the whole group implementation.
It does seem to come down to just that one difference- categories/tags are not installable while groups are. With that in mind, what drawback is there to using our existing group functionality for categories? I can think of the following issues (none of which are critical or unfixable): 1. Category names could potentially conflict with package names. Doesn't seem like it would happen in reality though. 2. Search output would get cluttered. I'm referring to the group display to the right of the package name. ("core/pacman 3.2.0-1 (base)") 3. Slight performance hit with nearly every package in a group. Surely we could improve our code/algorithms to accommodate if it was a big issue, and the categories/tags being separate would incur the same if not a bigger penalty. 4. OMG you could try to install a category! But don't we trust the user anyway? No need to handhold here and wave our finger saying "you can't do that". Anyone else have thoughts here? From the Arch perspective of things, we already added the base and base-devel categories as groups long ago, and there is no real reason other categories of packages couldn't do the same thing. And we allow as many groups as you want on a package. -Dan