On 8/21/08, Dan McGee wrote:

On Wed, Aug 20, 2008 at 5:42 PM, Xavier 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 _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

Ghehe, I'm starting to get the impresion that I'm alone in my view that they are different :p Well, in any case it was a nice exercise of getting to know the pacman code a bit. Let me give a final try to convince you that they serve different purposes. Suppose I want to in install a desktop environment, say kde. As you know, all official kde packages (so the complete DE) are part of the kde group. Therefore installing kde on arch is as intuitive as pacman -S kde. Now suppose we use the groups field for using tags. As you can imagine, kde would pop up in the group of quite a number of packages (amarok, digikam, koffice, kmess to name a few, but there are lots more, even excluding pure qt packages). So what do we now have? Instead of an easy install of the desktop environment (think new users, '-S kde' must be the first they try), in the new case, 'pacman -S kde' wants to install a shitload of packages, confusing the users. I can go on with different use cases, but I suppose I made my point, whether you share it or not ;). So can we work around it in the current groups only field ? Sure we can. We can define groups for easy installing things as we do at the moment. In the same field we could included categories in a way similar to 'groups=(category:kde)' for example. I much prefer a new field to include categories/tags as I think it is more use friendly. Besides that people tend to forget things and start writing 'groups=(kde)' where groups=(category:kde) should have been. Enough for now ;) Regards, Ronald

On Thu, Aug 21, 2008 at 10:45 AM, Ronald van Haren wrote:

I much prefer a new field to include categories/tags as I think it is more use friendly. Besides that people tend to forget things and start writing 'groups=(kde)' where groups=(category:kde) should have been.

Even if we come to the agreement that a new field is better, what Nagy said still holds. Groups and categories are both some kind of tags to packages. A huge part of their implementation will by consequent be the same and should be shared. So in my opinion, the brainstorming should go in that direction, to find out if that is possible and how to do it.