[pacman-dev] pacman tag support
Ronald van Haren
pressh at gmail.com
Thu Aug 21 04:45:04 EDT 2008
On 8/21/08, Dan McGee <dpmcgee at gmail.com> wrote:
> On Wed, Aug 20, 2008 at 5:42 PM, Xavier <shiningxc at gmail.com> wrote:
>> About the feature itself, here is the last thread where it was discussed :
>> 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 :
>> 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
> 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
> pacman-dev mailing list
> pacman-dev at archlinux.org
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 ;)
More information about the pacman-dev