You are not logged in.
Pages: 1
Topic closed
I have a system where many packages and package groups have been installed. I'd like to export a list of packages and package groups that have been installed manually. I can use
pacman -Qeto get a list of installed packages, but when those packages were installed in a group (like gnome) that command returns all of the packages names, not the group name.
Install command:
pacman -S vim gnomeExpected output of hypothetical command:
vim
gnomeActual output of current command:
adwaita-icon-theme
baobab
cheese
eog
epiphany
evince
file-roller
gdm
gedit
gjs
gnome-autoar
gnome-backgrounds
gnome-bluetooth
gnome-books
gnome-boxes
gnome-calculator
gnome-calendar
gnome-characters
gnome-clocks
gnome-color-manager
gnome-contacts
gnome-control-center
gnome-desktop
gnome-dictionary
gnome-disk-utility
gnome-documents
gnome-epub-thumbnailer
gnome-font-viewer
gnome-getting-started-docs
gnome-keyring
gnome-logs
gnome-maps
gnome-menus
gnome-music
gnome-online-accounts
gnome-online-miners
gnome-photos
gnome-remote-desktop
gnome-screenshot
gnome-session
gnome-settings-daemon
gnome-shell
gnome-shell-extensions
gnome-software
gnome-system-monitor
gnome-terminal
gnome-themes-extra
gnome-todo
gnome-user-docs
gnome-user-share
gnome-video-effects
gnome-weather
grilo-plugins
gtksourceview4
gvfs
gvfs-afc
gvfs-goa
gvfs-google
gvfs-gphoto2
gvfs-mtp
gvfs-nfs
gvfs-smb
libgnomekbd
libnautilus-extension
libsoup
mousetweaks
mutter
nautilus
nautilus-sendto
networkmanager
orca
rygel
simple-scan
sushi
totem
tracker
tracker-miners
vim
vino
xdg-user-dirs-gtk
yelpLast edited by christianbundy (2019-12-31 17:50:19)
Offline
man pacman | less -p --groupsOffline
The problem with the above is that you will get any group name for any package installed regardless of whether or not you installed that group as a group or more importantly whether or not you have the whole group installed.
You could write a script to generate a list of all groups for which you had the entire group installed ... but why? This sounds like an X-Y problem. Why do you want a list of the groups you installed? Groups are not like meta-packages -pacman doesn't care (or even know) if a package was installed as part of a group or not ... nor should you.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Thanks for the quick feedback.
My goal is to take an existing system and produce the list of groups and packages that would result in a similar system in the future. Getting the list of explicitly installed packages is simple, but if the existing system installed the gnome group then I'd like the new system to install the gnome group as well -- especially when the packages change.
If my existing system installed base-devel, I'd like the new system to also install base-devel. If the packages in base-devel have changed, then I'd like the new packages instead of the old one.
Offline
Then even the scripting option would fail. The only option would be to parse the pacman log for any group names included on the command line for installation. The following will do that much:
#!/bin/sh
pacman -Qg | cut -d' ' -f1 | sort -u | while read group; do
grep -q "Running 'pacman.*-S[yu]* $group" /var/log/pacman.log && echo $group
doneThough it will get false positives at least for any group that you ran a command like `pacman -S <group-name>` but then said 'N' at the prompt or otherwise cancelled the transaction. It will also include any group you've ever installed even if you've removed most (but not all) of the members of that group since then.
Last edited by Trilby (2019-12-31 20:03:56)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
This is interesting as I've never figured out how pacman deals with groups, and how/why "base" metapkg takes precedence over still existing "base" group. Possibly learn something about this.
Would this do what you're looking for? * This prints the group <name> if all the packages listed for it are installed. It would however, be possible that you have installed all the packages individually, belonging to a group, and then get a false positive result. It shows base group as being installed on my system (down to only 2 packages now), This system was installed before base metapkg.
* My first thought, is no, because Trilby is at least several orders of magnitude beyond my abilities for solutions to this stuff. There's always the possibility of plain old dumb lucky though. lol
#!/bin/bash
# list installed groups
for G in $(pacman -Qg | cut -d' ' -f1 | sort -u); do
Sgq=$(pacman -Sgq "$G") # package list of current group
Qgq=$(pacman -Qgq "$G") # packages installed from current group
if [[ $Sgq == $Qgq ]]; then
echo "${G}"
#4TESTING echo "Installed :${G}"
#4TESTING else
#4TESTING echo "Partially Install: ${G}"
fi
#4TESTING echo "$Qgq"|xargs ; echo
#4TESTING echo "$Sgq"|xargs ; echo
doneI also use AUR pkgbrowser. Makes it easy to get group related info, but not useful for scripting AFAIK. Also not sure how it gets that info, etc.
EDIT: Thinking out loud..
A combination of Trilby's reading pacman.log combined with something like my script could give accurate results?
And....this works on my system, and eliminated xorg-fonts group from the list, which I installed the packages, but not the group.
#!/bin/bash
# list installed groups
for G in $(pacman -Qg | cut -d' ' -f1 | sort -u); do
Sgq=$(pacman -Sgq "$G") # package list of current group
Qgq=$(pacman -Qgq "$G") # packages installed from current group
if [[ $Sgq == $Qgq ]] && \
grep -q "Running 'pacman.*-S[yu]* $G" /var/log/pacman.log
then
echo "${G}"
fi
doneLast edited by NuSkool (2020-01-01 01:26:19)
Scripts I Use : https://github.com/Cody-Learner
grep -m1 'model name' /proc/cpuinfo : AMD Ryzen 7 8745HS w/ Radeon 780M Graphics
grep -m1 'model name' /proc/cpuinfo : Intel(R) N95
grep -m1 'model name' /proc/cpuinfo : AMD Ryzen 5 PRO 2400GE w/ Radeon Vega Graphics
Offline
This prints the group <name> if all the packages listed for it are installed.
But that is not the goal. The only purpose for knowing which groups were installed were for the scenario where the members of those groups has changed - otherwise just the list of currently installed packages would suffice. If the member packages of a group change, then the current system may not have all the (new) members installed, but the OP still wants to know that the group had been installed.
For example, if base-devel was installed, and at some later date a new package is added to base-devel, any script that checks whether all members of the group are installed would not list base-devel - but the OP's goal is to list base-devel in these conditions.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
For example, if base-devel was installed, and at some later date a new package is added to base-devel, any script that checks whether all members of the group are installed would not list base-devel - but the OP's goal is to list base-devel in these conditions.
Ahh OK, sorry I didn't get the "in these conditions" from reading things. Please bare with me as I attempt to get my head around some of this stuff.
If the script was ran on an up to date system with proper maintenance, how could it not be accurate? Wouldn't the groups new package be be added during an update, or would you have to reinstall the group to get the updated list of packages?
As I understood, op originally wanted a list of installed groups?
Then he said:
If my existing system installed base-devel, I'd like the new system to also install base-devel. If the packages in base-devel have changed, then I'd like the new packages instead of the old one.
I interpreted "the new packages instead of the old one", to be the new and old "list of packages" installed by that group that may be different, which by installing the new group, it would also be the most recent list.
So I'm kind of getting he wants a package / group list to use to duplicate his install. The groups would not be needed though, except when a group had changed the "package list" that made it up, because the group can add or subtract packages over time?
And my reasoning:
The second version of my (and your) scripts combined would give a list of groups ( questionably accurate ), that could be used for a new install, and ran prior to the individual explicitly installed package list used with the pacman --needed flag? Although this would still install any packages that had been removed from a group over time?
Not having a clue how groups (among any others) work, but wouldn't those packages removed from a group possibly show as orphan if no other packages depended upon them? Do groups install packages as dependencies? Dependencies -vs- explicitly installed, would either show as potentially orphaned if unneeded?
Last edited by NuSkool (2020-01-01 03:12:28)
Scripts I Use : https://github.com/Cody-Learner
grep -m1 'model name' /proc/cpuinfo : AMD Ryzen 7 8745HS w/ Radeon 780M Graphics
grep -m1 'model name' /proc/cpuinfo : Intel(R) N95
grep -m1 'model name' /proc/cpuinfo : AMD Ryzen 5 PRO 2400GE w/ Radeon Vega Graphics
Offline
Wouldn't the groups new package be be added during an update
Of course not. How could this happen? If this were possible, it would mean that the pacman database maintained a set of installed groups, and we'd not be having this discussion as one could just query that list.
When you install a group, pacman offers to install all members currently in that group. From then on there's no difference between whether you installed each of those packages individually or as a group except in the command line recorded in the pacman.log. Pacman has no 'memory' of that group being installed. Packages are either explicitly installed, or installed as a dependency; there is no 'installed as a member of a group' flag.
If new packages are added to base-devel, they will not magically appear on the currently running system (before or after updates), so your script will not show base-devel as installed. As a result, base-devel would not be installed on the new system.
Your script will only work if the packages in the group never change. And if that were the goal, as you say here ...
So I'm kind of getting he wants a package / group list to use to duplicate his install.
If that were the goal, again, we'd not be having this discussion as the OP would simply need a list of currently installed packages, or `pacman -Qne`. The OP wants a list of groups that were installed on the system even if the group has changed such that they no longer have the entire group installed.
... wouldn't those packages removed from a group possibly show as orphan if no other packages depended upon them? Do groups install packages as dependencies?
No to both. You are confusing groups and meta-packages.
Admittedly, groups don't change all that often. So I don't see that there's much point in what the OP is seeking here. I'd advise that the OP just use the list from `pacman -Qne`. But if that really is insufficient, then any more complicated script had better do a better job than `pacman -Qne`.
Last edited by Trilby (2020-01-01 13:49:09)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Thanks for taking the time to explain in detail. I've learned some stuff during this exchange. I've always pretty much ignored groups for the most part, until the base group to metapackage change.
And a few more questions if you don't mind.
Where can I find detailed info on groups? I find the man pages and wiki lacking, although admittedly upon reviewing them, some if not all my questions so far could have been answered from those sources. (RTFM to self) I'd be completely lost clueless trying to read pacman C source code.
Where does the group member (package list) info come from when I run pacman -Sg or -Qg? The mirrors? (If so, light bulb lit up above head)
Why is there still both a base group and metapkg using same name? More choices?
I "could" install base group with 'pacman -S $(pacman -Sgq base)'. Is there a more straight forward way?
How could this happen?Well thinking for a moment, it seems possible with some scripting, but admittedly more off topic than this...
Last edited by NuSkool (2020-01-01 21:13:32)
Scripts I Use : https://github.com/Cody-Learner
grep -m1 'model name' /proc/cpuinfo : AMD Ryzen 7 8745HS w/ Radeon 780M Graphics
grep -m1 'model name' /proc/cpuinfo : Intel(R) N95
grep -m1 'model name' /proc/cpuinfo : AMD Ryzen 5 PRO 2400GE w/ Radeon Vega Graphics
Offline
Where does the group member (package list) info come from
From the individual packages. There is no "list of members of $group" stored anywhere in the pacman databases. Each package can claim to be a member in whatever groups they want. Groups only exist to the degree that some package(s) claim to be in them.
Why is there still both a base group and metapkg using same name? More choices?
Either a screw up, or the remaining two packages just haven't been rebuilt since the change. More likely the latter. But this is an exceptional case just due to the transition from group to meta-package.
I "could" install base group with 'pacman -S $(pacman -Sgq base)'.
For any actual group, you'd just do `pacman -S $groupname`, e.g., `pacman -S xorg`. Again, 'base' is in an odd transitional state for the moment so this doesn't work.
As for the "how could this happen" it was a rhetorical question: it's impossible. Yes, you could script some pacman wrapper that always checked that you had all members of various groups you wanted to install, but what is impossible is for pacman to magically know this without an elaborate wrapper script. The point is/was that the data needed to take these steps does not exist anywhere in the pacman databases/mirrors/etc.
Last edited by Trilby (2020-01-01 22:05:07)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I was trying to ignore MariaDB from updates, I thought I could blacklist it with group name but looks like it's not belong to any group
pacman -Qgsou I end up listing all it related packages and
pacman -Qqe | grep mariadbOffline
Not sure why you felt the need to necrobump a topic that has nothing to do with your question. Also, ignoring package upgrades leads into partial upgrade which isn't supported and shouldn't be generally done.
Closing this old topic.
Offline
Pages: 1
Topic closed