Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.

FS#8242 - Keep track of groups and allow upgrading them with pacman -Syu

Attached to Project: Pacman
Opened by sabooky (sabooky) - Sunday, 07 October 2007, 10:22 GMT
Last edited by Roman Kyrylych (Romashka) - Tuesday, 09 October 2007, 09:33 GMT
Task Type Feature Request
Category General
Status New
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Architecture All
Severity Low
Priority Normal
Reported Version 3.0.6
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 32
Private No


Summary and Info:

When doing pacman -Syu it only checks for packages that need to be upgraded, but doesn't install new ones that are part of a previously installed group.
For exmaple:
pacman -S gnome-extra
*few weeks later*
gnome-extra adds 2-3 new packages
pacman -Syu doesn't catch this and install the 2-3 new packages.

Either prompting the user, or maybe having an optional flag like pacman -Sygu or something like that would be nice.

Steps to Reproduce:
This task depends upon

Comment by Aaron Griffin (phrakture) - Tuesday, 09 October 2007, 15:38 GMT
I like this idea, BUT I can't think of a clean way to implement it.
Comment by Nagy Gabor (combo) - Friday, 26 October 2007, 20:21 GMT
A workaround: pacman -S gnome-extra --noconfirm <- however, this is slower and you should not clear package cache :-(
Aaron, it would be nice, if user can answer to (certain _type_ of) questions from command line somehow. Or at least set the default answer to --noconfirm. Or is this implemented yet? ;-)
Comment by Aaron Griffin (phrakture) - Friday, 02 November 2007, 00:00 GMT
This has nothing to do with questions.... solving this issue with noconfirm is messy. What we *should* do is literally keep track of whether something installed is a group or a package.
Comment by Nagy Gabor (combo) - Monday, 05 November 2007, 19:15 GMT
1. OK. That's why I wrote 'workaround'.
2. And my question was a bit offtopic here, I just wanted to know whether user can define answers to certain _type_ of questions [install whole content? yes; foo is up-to-date. install anyway? no ...], or in more general: how effectively can pacman run non-interactively (from a script for example)
3. Also, I think that my solution is much clearer.
'pacman -Su' just upgrades your system.
'pacman -S group' install/_upgrade_ the (whole) group. Usually I don't want to see all packages from _all_ of my "installed" groups on my HDD, so I must insert 'gnome-extra' to the command line somehow; and we reached to -S now. We should just implement an option to 'group-loadtarget' to only add outdated/not-installed packages to the target list [<=> this is exactly the noconfirm solution.]
Comment by Nagy Gabor (combo) - Tuesday, 13 May 2008, 13:55 GMT
I think this request could be satisfied using meta packages (on repo side).
I mean something like package "gnome-meta" which has no files, however has all packages of gnome group listed as dependency (with explicit version, including pkgrel).
I wouldn't add any complicated new stuff to pacman, we should do the bookkeeping about installed groups, which is almost the same as metapackages.
Comment by Xavier (shining) - Monday, 18 August 2008, 22:01 GMT
Nagy, what did you mean by "we should do the bookkeeping about installed groups, which is almost the same as metapackages." ?
Comment by Nagy Gabor (combo) - Monday, 18 August 2008, 22:35 GMT
I meant the following:
If I install one package from base-devel, this doesn't mean that I installed base-devel group. So an extra bookkeeping is needed after "pacman -S base-devel" to avoid chaos (store somewhere the "installed" groups) or user can manually select the installed groups (extra bookkeeping again). So in my definition "installed groups" is not the output of -Qg (first column), imho that would make the requested feature unusable.

If I wasn't clear earlier, my opinion: "Won't implement". Distros can solve this problem by using meta packages. User can do 'pacman -S base-devel --needed' (however, this is not an automatic process...)
Comment by Nagy Gabor (combo) - Monday, 18 August 2008, 22:38 GMT
"If I install one package from base-devel,"
Probably you understood, but this phrasing is better: If I have only one package installed from base-devel...
Comment by Craig King (kingc) - Thursday, 18 September 2008, 19:29 GMT
Metapackages are probably a much better approach than implementing more complicated, explicit group management.

My simple view is that there are 3 key advantages to metapackages:
1. The group definition is in one place - there is no need to tag each package in the set.
2. A single package can be a dependancy of a number of metapackages and therefore belong to multiple sets (not sure if this is possible in the current pacman group implementation).
3. The metapackage can be versioned, which of course links closely to number (1.) above.

I also think about it like this:
a. Metapackages: if I install a metapackage, all dependencies should be installed; removing the metapackage can still leave orphans which I can remove if I feel like it. In other words, works as anyone would expect any single package to work currently.
b. Explicit group: if I install the group, all dependencies should be installed; removing the group should remove all the dependencies. In other words, the operation should be actioned at the group level; if it is not so, what is the point of distinguishing between an explicit group and a package?

I personally much prefer route (a.) above - simpler and allows more control of the system.

Alternative group tracking is trying to solve a non-existent problem, IMHO - it would be nice to simplify pacman by removing it :)
Comment by Xyne (Xyne) - Thursday, 23 October 2008, 19:30 GMT
I like the idea of metapackages too. For what it's worth, I've written a metapkg creator (metapax: which does exactly what's been mentioned here, namely specify packages as dependencies. The only disadvantage of this is that you can't remove single packages as you can with groups. A better option would be to create metapkgs with all the pkgs specified as optdepends and create an efficient way to handle optdepends during installation.

I've suggested a way to do this in a previous feature request:

Whether you choose to improve groups or create metapkgs, it would also be nice if there were a way for users to create their own so that they can manage pkgs more easily (during migration, re-installation, etc).

If it's of any use, I've written a script to check which packages are "missing" from a locally installed group:
Comment by Bill Kountouriotis (yourself) - Friday, 24 October 2008, 12:08 GMT
Coming from distros like debian, I also think that metapackages should be the way to go and definitely not "hack it" in pacman.

This is a very clean solution to this issue and all existing users have to do is issue a couple of "pacman -Sy <metapackage>" commands to get all the benefits from that system. Of course, it would be wise to update all installation guides to point to the new metapackages and not groups. The last point is very important as it is far from obvious to a new user that groups are not metapackages and will not "self-update". I myself fell for that and kept wondering why gnome-extras did not contain the new packages.

Imho, this issue is pretty serious as it could potentially drive people away from this wonderful distribution when they discover that "arch's package manager could not even bring gnome up to date!!" and we should take care of it asap.
Comment by Ajay (ashyanbhog) - Saturday, 25 October 2008, 08:00 GMT
This should already be possible without requiring any modifications to pacman at all,

# Create a package specifying all the packages as dependencies. This will install all the packages. For example, a kdemod-all-themes-4.1.2 package can pull together all themes in extragear without having to install each of them manually
# If there is a new package addition, add it as another dependency and update the package. So if there is a new theme addition, add it as another dependency and release a KDEmod-all-themes-4.1.2-2.pkg.tar.gz

For the build section, create a dummy hello world package, maybe we can send dummy file installation to /dev/null, though i'm not sure of how pacman will behave when uninstalling in that case.

When removing the package, use the -s option, Since all other packages where installed as dependcies, pacman should remove them as well (if nothing else is using it ofcourse). Skip the -s if you want uninstall them manually later.

I'll try and rig up a AUR package that does just this to see how it pans out, if I find time today
Comment by Craig King (kingc) - Saturday, 25 October 2008, 08:45 GMT
The metapackage concept works just fine with pacman. As Xyne mentioned, he has a script to create metapackages, and I created my own to create metapackage equivalents of each group. As you say, the pkgbuild simply has a dummy build method. The problem I discovered is that some of the existing groups are version-based (e.g. at-spi>=*). This seems to be a bit of a hack - most likely because the group is specified as a dependency for some other package and the current pacman groups have no version concept (which metapackages would obviously solve!).

So, basically the ideal in my view would be:
1. Remove the group concept from pacman completely since it really has no advantages over metapackages and simply adds complexity to the tree.
2. Create metapackages for the existing groups in core and extra and maintain groupings here going forward.

Functionality just needs to be removed from pacman and the pkgbuild spec for (1), but both require buy-in from the devs.

Xyne, you say "The only disadvantage of this is that you can't remove single packages as you can with groups". I'm not sure I see the disadvantage (groups and metapackages should function as a unit, if you don't want the whole unit, install whichever dependencies you want, manually?).

Personally, I would love an official "base" metapackage so that I don't see all the core installation packages when issuing pacman -Qe. Makes it much easier to do admin. I am currently getting around this by building a "base" metapackage. Using the quickinstall script, modified to install the initial packages --asdeps and then explicity installing the "base" metapackage afterwards. So after an initial install, I just see "base" as explicit, with all the true base packages listed as dependencies of it. Incidentally, some of the initial packages are no longer in the "base" group once pacman is sync'd after installation (e.g. lilo), so these become orphaned and are removed easily. Nice clean system.

Comment by Bill Kountouriotis (yourself) - Saturday, 25 October 2008, 10:30 GMT
Well, I was a bit reluctant to say in the first place, but now it's mentioned, it's my opinion too that groups should be dropped in favor of metapackages. Imho, I see no obvious advantage of having a group as a shortcut for some packages and *not* wanting it updated. In the recent example, why would anyone want to have *all* the gnome-extras for gnome 2.22 but *not* all of gnome 2.24 extras?

To my understanding, the group concept just has only the use of shortening this
$ pacman -Sy <insert> <here> <every> <one> <of> <the> <contents> <of> <a> <group>
to this
$ pacman -Sy <group_name>

whereas the metapackage offers this as well as a corectly upgraded system, as per users' expectations.

Advanced users who want (for some reason) the behaviour of groups could obtain it easily by first installing the metapackage and then removing it (but leaving its dependencies intact). In fact, this could be a very nice little option of pacman: install all dependencies but not the actual requested package, and lo and behold, you get group behaviour.

Furthermore, normal users will just install a metapackage and stay current for ever by doing pacman -Syu.

Simple, elegant and intuitive.
Comment by Allan McRae (Allan) - Sunday, 26 October 2008, 00:12 GMT
Groups have the advantage that you do not have to install everything in them. You have choice, which is very much in line with Arch's philosophy. If you want a meta-package, create one and put it on the AUR.
Comment by Craig King (kingc) - Sunday, 26 October 2008, 08:30 GMT
What a pity.

You do not *have* to install everything in a metapackage, either - you *can* choose to install individual dependencies, your choice.

I would think that the metapackage concept fits in very well with Arch's philosophy, especially since it in fact simplifies and *correctly* satisfies the whole group concept.
Comment by Ajay (ashyanbhog) - Sunday, 26 October 2008, 18:20 GMT
Finally got around to making the test metapackage,

PKGBUILD is stripped to the bare minimum, and some kdemod-extragear-kstyles are listed as dependencies. In a couple of days I'll updated the PKGBUILD to add some more syles that was intentionally left out to show the upgrade in action later on.

To keep makepkg happy, I had to pass a echo to /dev/null, thats it. Keep it simple in action.... I love Arch.

I'll add a couple of more dependencies later, so if any of you have installed the metapackage, you should see the additional installs happening, then,

PS: To use the metapackage like a group (for a one time installation,), say yes to install all dependencies and say no when installing the metapackage itself. This will give you the freedom to remove installed dependencies later on without having to use the --nodeps option. But any changes/upgrades to metapackage wont get reflected on your system, just like groups.
Comment by Xyne (Xyne) - Wednesday, 29 October 2008, 07:41 GMT
@ Craig King
As already mentioned, it's an advantage to be able to choose which packages to install from a group/metapackage. If the metapackage specifies everything as a dependency, you have to remove it to be able to remove others (as you mentioned), which leaves us back at the problem with automatic updates (installing the metapackage every time to ensure a complete update would is no better than specifying the group each time). I get around this as best as possible in metapax by using simple lists to specify the packages to include. It's easy to dump the list for a metapkg, change it, then rebuild it with just a few commands, but this is far from ideal. I also added options to easily change the install reason for packages or dependencies of packages. With that, I can change all the deps of a metapkg to explicit and remove then remove the metapkg.

The best way would be to make pacman actually handle optdepends (there is no such thing right now... "optdepends" just means that pacman will print a few lines to the console). With that, metapackages could specify packages as optdepends, which could then be installed and removed while leaving the metapackage in place.

It would also be nice to let users create their own metapkgs easily (my reason for making metapax, other than wanting to reduce the clutter in my -Qet list), but I doubt that would be included in pacman.

Comment by Aaron Griffin (phrakture) - Sunday, 09 November 2008, 05:32 GMT
I'm going to throw my support behind the "remove groups in favor of metapackages" camp here. It makes a lot of sense to me. Let's face it, even if we used a 'base' metapackage, I can still do "pacman -S base --ignorepkg lilo" to skip some content. Using IgnorePkg for optional content here seems to make a lot of sense.

Just my opinion though. I trust Dan and Xavier to do the best thing for pacman here.
Comment by Xavier (shining) - Sunday, 09 November 2008, 07:01 GMT
Isn't this only a packaging problem, and not a pacman problem?
It's already possible to make metapackages as Ajay showed. It's just that packagers seemed to prefer using groups until now (remember the xorg metapackage -> group switch?). I am not even sure why though.
But in any cases, it is the discussion and a decision that packagers/developers need to do.
Comment by Nagy Gabor (combo) - Sunday, 09 November 2008, 13:13 GMT
I always support ideas which simplify alpm code. Metapackages can solve this "keep track of groups" issue.

But groups are still needed imho (atm). Back to Aaron's example: "pacman -S base --ignorepkg lilo". If lilo is a dependency of base, pacman will stop with unsatisfied dependencies. So "group members as dependencies" won't work. Optdepends may be better, but in this case we need some user interaction (in git, pacman lists only the *new* optdepends during upgrade, this is ideal here). In the future we may improve our optdepend stuff: Ask the user which optdepends he wants to install (this is ~identical with current group implementation), but optdepends are too "weak" atm: -Rs base won't remove them, -Rs otherpkg can remove them, ... So there are many things around optdepends which is not decided/implemented yet...
Comment by Aaron Griffin (phrakture) - Monday, 10 November 2008, 18:30 GMT
Hmmm I didn't know pacman -S base --ignorepkg lilo would fail. I remember this working in the past - if a dep is ignored, it carried on. Am I imagining it, or was this functionality removed?
Comment by Xavier (shining) - Monday, 10 November 2008, 19:13 GMT
"pacman -S base --ignorepkg lilo" works if base is a group, but not if base is a meta-package. Because pacman does not allow to break dependencies.
pacman can only break dependencies when explicitly asked with the -d option, but this skips the whole dependency resolving.
So with base as a meta-package, pacman -Sd base would install only the base meta-package and none of its dependencies, which is quite useless :)
Comment by Nagy Gabor (combo) - Monday, 10 November 2008, 22:36 GMT
A bit off-topic:

Aaron: "Am I imagining it, or was this functionality removed?"
Maybe you are right, but I haven't ever heard about this => Since deps.c was deeply reworked by me some years ago, and this (new?) behavior was intentional from my side, you can blame me ;-) Atm only -Sd let you break any dependency.

Btw, your preferred(?) behavior is also reasonable, but I would introduce IgnoreDep for this purpose (for resolvedeps and checkdeps). In fact, optdepends now superseded "not so important" dependencies, and the current pacman devel team is quite conservative in this regard (consistent database), testdb would report broken database etc. If you want, I/we can implement this (you are the boss:-).
Comment by Gavin Bisesi (Daenyth) - Thursday, 13 November 2008, 02:21 GMT
For what it's worth I highly prefer the current group usage, and consider groups over metapackages to be one of the better things about pacman compared to others.
Comment by Olivier (litemotiv) - Wednesday, 23 September 2009, 07:34 GMT
is this discussion still active?

i also bring my vote for either tracking groups or using a different metaformat. mainly because there seems no easy way to find and display groups with pacman unless you specifically know the names, which is especially confusing for newer users.

pacman -Ss "xorg"

should print out a listing like this by default:





(optionally with parameters to list only groups/packages)

i'll stay out of the technical discussion! ;-)
Comment by Dan McGee (toofishes) - Wednesday, 23 September 2009, 13:36 GMT
Try taking a look at "pacman -Sg".
Comment by Olivier (litemotiv) - Wednesday, 23 September 2009, 14:16 GMT
thanks Dan, but i meant "search and display", not just inspecting a specific group name. when i search for 'xorg' or 'kde', the appropriate groups should ideally be listed first along with a description, since it is more likely that i will want to install the group than one of it's children when searching for generic terms. it's also good to list the largest common denominators first. now the groups aren't listed anywhere except behind certain package names in a long list, which isn't very clear in meaning.
Comment by trusktr (trusktr) - Tuesday, 01 November 2011, 19:31 GMT
I was just thinking about this today. Has this been implmented yet? Meta packages for gnome and gnome-extra would be convenient. I saw one in AUR, but not in official.

Is there a way to automatically detect what gnome packages are released?
Comment by Alexander F. Rødseth (xyproto) - Sunday, 29 January 2012, 02:15 GMT
Is it possible to figure out which groups are currently installed by looking at /var/log/pacman.log? (by searching for -S and -R, for example)?
Comment by Xavier (shining) - Sunday, 29 January 2012, 09:43 GMT
pacman -Qg should give you a clue.
Comment by Alexander F. Rødseth (xyproto) - Sunday, 29 January 2012, 11:17 GMT
Thanks, Xavier. Then the information is stored somewhere. Wouldn't that mean it should be possible to check at upgrade time if: a package belongs to an installed group, if the group has additional packages since last time and then install them? If the group has fewer packages since last time, pacman could ask if one wanted to remove them?
Comment by Ionut Biru (wonder) - Sunday, 29 January 2012, 11:24 GMT
why would you want to do that? Lets take as an example gnome-extra group. If i add couples of packages into that group, I don't want them to be installed automatically.
Comment by Xavier (shining) - Sunday, 29 January 2012, 11:30 GMT
Sorry if it was not clear, it helps the user to deal with it manually: you can maintain a list of the groups you want fully, and regularly do pacman -Syu --needed on that list.
Comment by Alexander F. Rødseth (xyproto) - Sunday, 29 January 2012, 11:33 GMT
Ionuț, that's true, but if there were an option for it, I think it would be useful.
Comment by Mark (voidzero) - Monday, 16 April 2012, 15:26 GMT
Hopefully the following comment makes some sense: if you manage an Archlinux system with Puppet, there is no way to check whether a group has been installed. If you tell Puppet that a group must be installed then it will reinstall the group each time. I'm not aware of any workaround for this atm other than specifying individual packages which is a tedious task.
Comment by trusktr (trusktr) - Monday, 16 April 2012, 19:54 GMT
[root@rocketship ~]# pacman -Syu
Packages found but not installed from group gnome-extra.
package-nameXX.XX package-name-otherXX.XX
Would you like to install them? [Y/n] y
Comment by Pablo Lezaeta (Jristz) - Wednesday, 07 September 2016, 07:56 GMT
Any new info from this? regrected patched on the mailist or work in the git repo?

so far meta-packages like linux-tools-meta are the closest to a solution for this.