On Wednesday, September 03, 2014 23:13:04 Tai-Lin Chu wrote:

On the other hand, I think we should remove category because only a few packages actually use correct category. It is almost useless.

I personally try to put things in the proper category, but I would also second just dropping categories completely. I honestly don't think that it adds anything terribly useful to the AUR, but that may just be me. Can we get any kind of statistics from the web interface regarding how often people sort by or search for certain categories? That would give us an idea of how much that feature is actually used.

What happens if something really belongs in two categories? In that case, one should use a tagging mechanism instead of a categorization mechanism.

On the other hand, I think we should remove category because only a few packages actually use correct category. It is almost useless.

+1 — Jeremy "Ichimonji10" Audet

[...]if they can be parsed by pacman somehow, they would add some use. Otherwise, I'm ok with deleting them.

Am 05.09.2014 um 00:51 schrieb Hugo Osvaldo Barrera: pacman has no AUR support, this was a decision. So the only way to allow it to see such data would be to add it to the PKGBUILD or other metadata (which does not make sense, as the official repositories have no categories either). Anyways, there are quite a few AUR helpers available, so you could use them with a bit of shell scripting or use the RPC interface directly. To display categories for your installed AUR packages: $ cower --info --format="%c/%n" $(pacman -Qqem) | sort You may add a '| grep games' to filter for specific category or tell cower to sort by install date or something instead of using 'sort' of course. best regards, carstene1ns

still we have tons of packages that do not follow category. Searching by category is ineffective. I think the best way to know about package is to let users write "aur packages reviews" for the packages they love. On Thu, Sep 4, 2014 at 6:43 PM, Hugo Osvaldo Barrera wrote:

On 2014-09-05 02:59, carstene1ns wrote:

...

...

[...]if they can be parsed by pacman somehow, they would add some use. Otherwise, I'm ok with deleting them.

Am 05.09.2014 um 00:51 schrieb Hugo Osvaldo Barrera: pacman has no AUR support, this was a decision. So the only way to allow it to see such data would be to add it to the PKGBUILD or other metadata (which does not make sense, as the official repositories have no categories either).

Adding it to the PKGBUILD was what I originally mentioned.

...

Anyways, there are quite a few AUR helpers available, so you could use them with a bit of shell scripting or use the RPC interface directly.

To display categories for your installed AUR packages: $ cower --info --format="%c/%n" $(pacman -Qqem) | sort

Non-AUR packages don't have this metadata, so that seach would not include a lot of installed packages. (which I why I proposed the above).

...

You may add a '| grep games' to filter for specific category or tell cower to sort by install date or something instead of using 'sort' of course.

best regards, carstene1ns

-- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text?

On 05/09/14 18:42, Nowaker wrote:

...

"pacman -Q --category=games" => pacman -Qs game

pacman -Ss game | grep -i openttd | wc -l 0 ;-)

Well sure. But I said it was never going to be as accurate as filtering by a specific category, so it will be easy to come up with any number of false positives/negatives.

Anyway, totally agree categories are bad. Tags on the other hand are cool. I'd really enjoy searching by tags. Description isn't a good place for listing all the features or use cases. Consider this:

pacman -Ssx libvirt => show both libvirt, qemu, virt-manager, virtkick and opennebula

pacman -Ssx storage => show bacula, dropbox, owncloud (even the webapp), glusterfs, ceph, zfs etc.

Tags would be no better or worse than categories or descriptions (or any other equivalent scheme). Like I said: the elephant in the room is the huge cost of categorization/tagging (or whatever). Without accurate meta-data, no prospective scheme is going to be any better than the current solution of simply searching for keywords in descriptions. (If a keyword can be missing from the description, it can just as easily be missing from the tags/categories).

On 05/09/14 23:38, Nowaker wrote:

The thing is description is to *describe* the package in a few words. It's not for categorization.

There's a lot of overlap between describing and categorizing. The pkgdesc is free-form text, so there's no reason why a few extra words can't be added to help with searching.

Should tags be present, people will just assign them. Just like they already provide url= or license=, although there is no functional gain from having them. They just exist in PKGBUILD wiki & template and most people happily use them. Just add tags= to the template, and after a year most packages use it too.

The OP's use-case was searching for *all* the installed games on his system. Your form of tagging wouldn't provide a solution for that, because it just attaches optional, arbitrary flags to the package meta-data. (In fact, it's effectively the same as adding a few extra words to the description). True categorization requires that all packages have at least one category assigned to them from a controlled list. The only genuine purpose of categorization is to help with searching. If there are too few, or too many categories, or if the categories aren't assigned properly, it can quickly become useless (this is pretty much the current situation with the AUR). It's actually a little strange that pacman doesn't currently provide any form of categorization, because almost all other package managers do. I don't think this has got anything to do with KISS, or because it's an inherently flawed idea; I think it's simply because no one has so far been sufficiently motivated to pay the cost of actually implementing it. (And also maybe because there has never been much real demand for it from the arch community as a whole).