How to identify and separate standalone applications from libraries in Linux package lists?
I want to generate a list of trending Arch/AUR packages that focuses on user-facing applications rather than background libraries and dependencies.
I wrote a script that uses the data from pkgstats to show packages sorted by popularity. However, it doesn't distinguish between applications and libraries, so the output isn't very useful.
I want to identify and separate standalone applications from libraries and dependencies for both Arch official repositories and AUR packages. Not just for installed packages but for all of them.
pamac, Graphical Package Manager for Manjaro Linux with Alpm, AUR, Appstream, Flatpak and Snap support, seems to identify applications vs libraries/dependencies when grouping packages into categories like "Music & Audio" or "Games". As seen in this code, pamac gets categorized package lists and populates the UI accordingly.
Since it may not be clear what libraries or dependencies are and I'm already using pamac as an example. I'll consider packages that appear in pamac's categories like Games and Music & Audio as applications, and other packages as libraries/dependencies.
As an alternative, I would consider end-user software the ones that aren't required by any other packages. This isn't perfect, just good enough. For example, this is how I would do this for installed packages.
How can I identify standalone applications and separate them from libraries/dependencies in the Arch/AUR package lists? The end goal is a trending packages list focused on end-user software rather than background components.
1 answer
This answer is not directly usable under Arch, since I don't know the tools there. I show you a way to do it on Debian, which may inspire you to find a similar way in Arch.
With apt-file(1), you can list the files that a package provides. From that list, you can see if the package provides files in /usr/bin/ or in /usr/lib/. It's not a perfect approach, since it may provide files in both, in which case you're on your own. Of course, in Debian it would be easier, as libraries are named using lib* for runtimes, and lib*-dev for development files, but this is just for demonstration of the technique.
$ apt-file show libncurses-dev \
| pee \
"grep -m1 '/usr/bin/'" \
"grep -m1 '/usr/lib/'";
libncurses-dev: /usr/bin/ncurses6-config
libncurses-dev: /usr/lib/valgrind/ncurses.supp
$ apt-file show libncurses6 \
| pee \
"grep -m1 '/usr/bin/'" \
"grep -m1 '/usr/lib/'";
libncurses6: /usr/lib/x86_64-linux-gnu/libform.so.6
$ apt-file show libbsd-dev \
| pee \
"grep -m1 '/usr/bin/'" \
"grep -m1 '/usr/lib/'";
libbsd-dev: /usr/lib/x86_64-linux-gnu/libbsd-ctor.a
$ apt-file show libbsd0 \
| pee \
"grep -m1 '/usr/bin/'" \
"grep -m1 '/usr/lib/'";
libbsd0: /usr/lib/x86_64-linux-gnu/libbsd.so.0
$ apt-file show coreutils \
| pee \
"grep -m1 '/usr/bin/'" \
"grep -m1 '/usr/lib/'";
coreutils: /usr/bin/[
$ apt-file show pass \
| pee \
"grep -m1 '/usr/bin/'" \
"grep -m1 '/usr/lib/'";
pass: /usr/bin/pass
0 comment threads
1 comment thread