Arch Linux

I like this idea, BUT I can't think of a clean way to implement it.

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? ;-)

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.

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.]

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.

Nagy, what did you mean by "we should do the bookkeeping about installed groups, which is almost the same as metapackages." ?

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...)

"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...

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 :)

I like the idea of metapackages too. For what it's worth, I've written a metapkg creator (metapax: http://bbs.archlinux.org/viewtopic.php?id=53788) 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: http://bugs.archlinux.org/task/11337

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: http://bbs.archlinux.org/viewtopic.php?pid=439075#p439075

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.

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

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.

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.

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.

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.

Finally got around to making the test metapackage,

http://aur.archlinux.org/packages.php?ID=20991

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.

@ 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.

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.

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.

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...

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?

"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 :)

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:-).

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.

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:

[groups]

Xorg x.x.xxx
Description

[packages]

....

(optionally with parameters to list only groups/packages)

i'll stay out of the technical discussion! ;-)

Try taking a look at "pacman -Sg".

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.

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?

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)?

pacman -Qg should give you a clue.

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?

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.

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.

Ionuț, that's true, but if there were an option for it, I think it would be useful.

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.

[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
.....

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.