It'd also be cool to have the option to exclude secondary splits from the search results.

There is no such thing as "primary" and "secondary" packages. There are package bases (exactly one per source tarball) and packages (at least one per source tarball). Are you suggesting to add a page to search for package bases? What is a use case for this? I won't implement this feature just to get some numbers "right". Could you please elaborate on this?

Actually, I was indeed talking about the "primary" packages, not the package bases themselves. When looking through e.g. the kernels for the outdated ones, I dislike having the -docs and -headers in the search results, when I'm only interested in a single result for each package. This would also be the case when simply browsing the list for all the different packages there is. Another confusing example is the results for 'xorg-server': https://aur.archlinux.org/packages/?O=0&K=xorg-server (this one would be a complete mess, if all these were properly spit, not just mine)

I'm not sure what kind of results would a simple package base list produce, when these don't have versions or even descriptions, and you'd mainly be interested in the "primary" packages anwyay.

Could you please be a bit more precise? What is your definition of a "primary" package? How is the AUR supposed to distinguish between "primary" and "secondary" packages? Why is your example a mess (I don't think it is)? How is the output different than what we had before split packages were supported?

With "primary" I'm referring to the one with the name of the package base, everything else I call "secondary" (the ones we can now see since AUR 3.0.0). The example is a mess when you actually try to look at the descriptions, as to what each of these packages do. It is very hard to figure out how many different "main" ones there are, as well as which of these are "secondary" (the ones we don't care). And this is even before all the other ones are split, too.

What I'd like is to preferably not only have the option exclude the "secondary" packages from the search results, but also distinguish them in _any_ results by, e.g. 1) having a separate category, 2) adding "(split)" after the package name, and/or 3) having the name in italics. This is simply because the "primary" package always faces the biggest value (or at least _I_ have yet to look for a "secondary" package in the AUR, which are finally shown).

There is not always a package that matches the package base name (see pkgbase="foobar", pkgname=(foo bar)).

Also, if you don't set a package base name, the package base will always refer to the first package name listed. I don't think it is a good idea to declare the first package listed as the "main" package. This is particularly wrong when the split package provides to flavors of the same software (e.g. foo-qt4 and foo-qt5).

I see you already closed this, but thinking about it I suppose the only way to do this would be to set some "split/secondary = true/false" flag in the .AURINFO and/or provide a button (or the category) in the Web interface, so that by default only the package that matches the name of the base (and only if one exists) would get the "main package" bit set, and any others should be manually set.

If set through the category, would this still be too inconvenient to implement?

Otherwise the only solution to the current X.Org Server mess (for now) would be for me to prefix the descriptions with something like "(split)" or "(partial)" in the .AURINFOs.

We are not going to add any AUR-specific fields to .AURINFO since that file is supposed to be generated by makepkg(8) (and renamed to .SRCINFO) at some point. Please, also don't add such a suffix to the package descriptions.

I still don't understand why people would need to find the "primary" package. Users look for a specific package, use the search form, then download the source tarball. They don't care if you consider the package they are downloading "prinary" or "secondary". Also, as I explained before, there isn't always a "primary" package. Sometimes, all packages inside a split package are equally important.

But that only works, when you know what to look. If you are just browsing the list by the descriptions (to see what they do), it becomes practically impossible as the packages are split in more parts and the descriptions only describe a dependent component. This is especially true in cases like the X Servers (you are not going to look for "xorg-server-xephyr-dev" in the AUR, only to notice it is a component of "xorg-server-dev").

With the kernels you get 2 to 3 times the same results, despite the fact that you're not going to really care about the headers and documentations: https://aur.archlinux.org/packages/?C=19&SeB=n&K=linux

Also, I mentioned that in those few cases where all the packages are equally important in terms of searching (or as "individuals"), then the "split"/"secondary"/"you-name-it" category could be manually switched from in the Web interface. They are certainly less numerous than the splits that are only secondary.

I am still not convinced that this is very useful. The AUR web interface has never been designed to allow for executing complex queries. If you really need this feature, why don't you simply write a tiny tool to query the AUR RPC interface and present the results the way you want? There are a lot of AUR helpers around, so maybe one of them already supports this.