[aur-general] Categories
Hi, I've some stuff I'd like to discuss regarding AUR categores. To begin with, categories are package metadata that lives in the AUR only. The PKGBUILDs have no reference to them, nor does pacman. This is really inconsistent with all of the other package variables, so I'd just like to propose we move this from merely being AUR metadata to the PKGBUILDS themselves, adding a "category" variable to them, eg: category="games" This would also leave the door open for pacman to process these variables in future, which could also be useful. I can't be the only person who's wanted to do something like "pacman -Q --category=games" to look for installed games. (the example syntax is horrible, but it's just to make it understandable). Any opinions? Downsides? Comments? Cheers! -- 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 Thu, Sep 4, 2014 at 1:42 PM, Hugo Osvaldo Barrera <hugo@barrera.io> wrote:
This is really inconsistent with all of the other package variables, so I'd just like to propose we move this from merely being AUR metadata to the PKGBUILDS themselves, adding a "category" variable to them, eg:
category="games"
How about tags=(awesome cool game)? </sarcasm> I don't think this sort of thing belongs in the package metadata. For one thing, categories are arbitrary. For another, no upstream is defining a category for their software. We have package groups in pacman which is quite different from what you're proposing, and packages are added to the same group only if it makes complete sense.
On the other hand, I think we should remove category because only a few packages actually use correct category. It is almost useless. On Wed, Sep 3, 2014 at 11:07 PM, lolilolicon <lolilolicon@gmail.com> wrote:
On Thu, Sep 4, 2014 at 1:42 PM, Hugo Osvaldo Barrera <hugo@barrera.io> wrote:
This is really inconsistent with all of the other package variables, so I'd just like to propose we move this from merely being AUR metadata to the PKGBUILDS themselves, adding a "category" variable to them, eg:
category="games"
How about tags=(awesome cool game)? </sarcasm>
I don't think this sort of thing belongs in the package metadata. For one thing, categories are arbitrary. For another, no upstream is defining a category for their software.
We have package groups in pacman which is quite different from what you're proposing, and packages are added to the same group only if it makes complete sense.
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.
On Thu, Sep 4, 2014 at 2:13 PM, Tai-Lin Chu <tailinchu@gmail.com> wrote:
On the other hand, I think we should remove category because only a few packages actually use correct category. It is almost useless.
Completely agreed, except I'd say there is no such thing as "correct category"... The category list in AUR sucks. If you think of categories as fruits, then AUR lists banana, apple, and moo-cow.
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
On 2014-09-04 14:07, lolilolicon wrote:
How about tags=(awesome cool game)? </sarcasm>
Well, my goal is to sometime be able to search installed packages quickly. I have installed some games of which I can't recall their names, and there's really no quick way to search for them in pacman - that was my main motivation for more metadata, especially since we already have categories. On 2014-09-04 16:57, Jeremy Audet wrote:
What happens if something really belongs in two categories? In that case, one should use a tagging mechanism instead of a categorization mechanism.
Agreed. Like minecraft-server, which is a game and a daemon, just to name one. As-is, I don't think categories add much value or are worth keeping, if they can be parsed by pacman somehow, they would add some use. Otherwise, I'm ok with deleting them.
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
Cheers, -- 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?
[...]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
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?
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 <hugo@barrera.io> 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 04/09/14 06:42, Hugo Osvaldo Barrera wrote:
I've some stuff I'd like to discuss regarding AUR categores.
To begin with, categories are package metadata that lives in the AUR only. The PKGBUILDs have no reference to them, nor does pacman. This is really inconsistent with all of the other package variables, so I'd just like to propose we move this from merely being AUR metadata to the PKGBUILDS themselves, adding a "category" variable to them, eg:
category="games"
This would also leave the door open for pacman to process these variables in future, which could also be useful. I can't be the only person who's wanted to do something like "pacman -Q --category=games" to look for installed games. (the example syntax is horrible, but it's just to make it understandable).
Any opinions? Downsides? Comments?
How would a category variable be a significant improvement over: description='some game featuring cool stuff' By default, both pacman and AUR search by name and description. Of course, this is never going to be as accurate as filtering by a specific category - but is such accuracy really feasible? Most packages just don't fit neatly into a single, well-defined category. And if the category variable is allowed to be an array, it soon becomes no more effective than a carefully written description. But in any case, the elephant in the room here is the huge, up-front cost of (re-)categorizing all the packages. Without that effort, it's doubtful whether adding a category variable would give better results than simply searching the name/description for the equivalent keywords. tl;dr "pacman -Q --category=games" => pacman -Qs game
"pacman -Q --category=games" => pacman -Qs game
pacman -Ss game | grep -i openttd | wc -l 0 ;-) 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. -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
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 Sep 2014, at 00:51, Hugo Osvaldo Barrera <hugo@barrera.io> wrote:
On 2014-09-04 14:07, lolilolicon wrote:
How about tags=(awesome cool game)? </sarcasm>
Well, my goal is to sometime be able to search installed packages quickly.
I have installed some games of which I can't recall their names, and there's really no quick way to search for them in pacman - that was my main motivation for more metadata, especially since we already have categories.
Just add a ‘game’ group to the PKGBUILD before you build the package and ´pacman -Sg games`
(If a keyword can be missing from the description, it can just as easily be missing from the tags/categories).
The thing is description is to *describe* the package in a few words. It's not for categorization. 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. -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
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).
On Wed, Sep 3, 2014 at 10:42 PM, Hugo Osvaldo Barrera <hugo@barrera.io> wrote:
This would also leave the door open for pacman to process these variables in future, which could also be useful. I can't be the only person who's wanted to do something like "pacman -Q --category=games" to look for installed games. -snip-
This is not a new idea and has had lots of previous discussion. See the bugtracker [1]. ~Celti [1] https://bugs.archlinux.org/task/7132
participants (10)
-
carstene1ns
-
Hugo Osvaldo Barrera
-
Jeremy Audet
-
Johannes Löthberg
-
kachelaqa
-
lolilolicon
-
Nowaker
-
Patrick Burroughs (Celti)
-
Robert Mackanics
-
Tai-Lin Chu