I may misunderstood you, but groups are ideal for doing this. Bye, ngaba ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

ngaba@petra.hos.u-szeged.hu wrote:

I may misunderstood you, but groups are ideal for doing this. Bye, ngaba

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

Not at all. Suppose say that all the text editors where in a group called editors. Then pacman -S editors would have installed all of them, and I very much doubt the possibility that anyone will ever need every available editor. The categories on the other hand are only a way of grouping packages for easier searching/browsing through them. This becomes especially valuable when you need a package from a certain category, but you are not acquainted with all of the possible options. Say you need a video player but you're new to the world of GNU/Linux. You haven't heard of mplayer, xine, vlc. But if there is category multimedia you just scan the packages in it and try them until you like some. So I think that a category info would be a most valuable asset to .PKGINFO and the community itself... The way I see it a package can belong to several categories at once - for example totem would be in both multimedia and gnome categories.

ngaba@petra.hos.u-szeged.hu wrote:

...

Not at all. Suppose say that all the text editors where in a group called editors. Then pacman -S editors would have installed all of them, and I very much doubt the possibility that anyone will ever need every available editor. The categories on the other hand are only a way of grouping packages for easier searching/browsing through them. This becomes especially valuable when you need a package from a certain category, but you are not acquainted with all of the possible options. Say you need a video player but you're new to the world of GNU/Linux. You haven't heard of mplayer, xine, vlc. But if there is category multimedia you just scan the packages in it and try them until you like some. So I think that a category info would be a most valuable asset to .PKGINFO and the community itself... The way I see it a package can belong to several categories at once - for example totem would be in both multimedia and gnome categories.

I still think, that groups are ideal for this ;-) After "pacman -S editors" you get a question if you want to install the whole group content or you wanna choose some packages by hand, this is useful for "categories" too imho. AFAIK packages can belong to multiple groups too. However, I'm not sure, that we can split groups between repos, but probably we can. Bye, ngaba

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

Every component of a package management system should have only one well defined and clear purpose. Groups should not be use out of their originally intended context and the inclusion of categories information would be very easy and straight-forward. It would require the addition of only a couple of methods to libalpm and pacman. The packages that do not currently include category info in their .PKGINFO file will be considered members of some standard category - say "Others", or will be considered to simply have no category and will be outside the scope of the tools that deal with categories. Then each maintainer while preparing the release of the new packages maintained by him will simply add the category info and in a couple of months most packages will be using this system. If the developers don't have the time/desire/manpower to look into my suggestion I will personally volunteer to provide a sample implementation which that they may consider. P.S. All other major PMS support categories - portage, yum, apt... Pacman should not lag behind.

2007/6/19, Xavier :

For the ones who check this ML, but not the forums (since lordbad always double post :d), phrakture gave a link to this : http://bugs.archlinux.org/task/7132

(thread is here : http://bbs.archlinux.org/viewtopic.php?id=34303 )

yeah, similar ideas about categories/tags/whatever were rised during SCM repo structure discussion, AUR2 brainstorming etc. Nice to see the idea didn't die :-) Though I'm not sure if it's worth to put categorization data into packages inself. Wouldn't webinterface-only categorization be enought for browsing/searchig packages? -- Roman Kyrylych (Роман Кирилич)

Dan McGee wrote:

On 6/19/07, Roman Kyrylych wrote:

...

2007/6/19, Xavier :

...

For the ones who check this ML, but not the forums (since lordbad always double post :d), phrakture gave a link to this : http://bugs.archlinux.org/task/7132

(thread is here : http://bbs.archlinux.org/viewtopic.php?id=34303 )

yeah, similar ideas about categories/tags/whatever were rised during SCM repo structure discussion, AUR2 brainstorming etc. Nice to see the idea didn't die :-) Though I'm not sure if it's worth to put categorization data into packages inself.

I disagree- when it deals directly with the package, why NOT include it in the description (PKGBUILD) of the package?

...

Wouldn't webinterface-only categorization be enought for browsing/searchig packages?

We try to make most things possible from the command line- I don't think we should limit ourselves to a web-interface only listing of categories either, especially if implementing it in both places (as opposed to one) is trivial anyway.

-Dan

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

I totally agree with you. And this does not concern only the command line clients like pacman. Suppose someone tries to implement a truly advanced GUI front-end for pacman(like synaptic for apt). What will this GUI list by default if not categories. This of course is only one of the many benefits for the users that the inclusion of such info would provide. I saw Aaron's proposal in the tasks list and I think it is ideal. One more thing - I do not think that if category support is included the names of the categories should the same as in the ABS - I see little sense in a category named "base" for example...