groups and meta packages

jpkotta · 2013-10-30 21:31:33

Is it a good idea to make a package that is empty but depends on other packages? How would this differ from a package group (or rather, why are package groups not implemented like this)?

I'm considering making some packages like this, for example a pylab package that depends on ipython, matplotlib, numpy, and scipy (maybe other packages too, like pandas, or stuff for ipython notebooks). I've tested it locally and it seems to work. I haven't come across any packages like this; maybe it's a bad idea or maybe just not a very compelling use case. Thoughts?

Xyne · 2013-10-30 21:55:39

I wrote a tool a long time ago (metapax) that could easily create such packages, but it proved less useful than expected. Ultimately the problem is that it provides little flexibility if you wish to install only some of the packages. Package groups permit this. The problem is that you have to track a group for additions and deletions if you want to keep it in sync. I wrote pkg-check_groups for this purpose.

Another approach would be to create an empty metapackage that lists all "group" members as optional dependencies, but there is currently no built-in way to easily install optional dependencies as dependencies with pacman. Makedep tries to address this, but it is not ideal.

Of course, the advantage of the metapackage approach is that a single package specifies exactly which packages are in (or out) the group. Anyone can include any package in a group by adding the group to the "groups" array, e.g. I could put all of the packages in my repo in the "base" group if I wanted to. I think I've seen at least one repo add something to this group. With a metapackage, only the metapackage maintainer can do this, so it makes it easier to manage the group and a little more reliable to install.

Arch Linux

#1 2013-10-30 21:31:33

groups and meta packages

#2 2013-10-30 21:55:39

Re: groups and meta packages

Board footer