[pacman-dev] Groups. Again.
xyne at archlinux.ca
Sun Oct 3 15:47:39 EDT 2010
> Hi list
> Jakob and I have been going back and forth about where groups handlings should
> be, in backend or frontend, and how alpm interface should look like.
> It turns out Jakob has several arguments for the group backend solution, and he
> spent quite some time working on it, improving and fixing things.
> This solution fixes several flaws that pacman currently has without drastically
> changing the code.
> There are just two disappointing aspects that Jakob covered below in bad news.
> Also there are still some points I would like to see improved, but more
> aesthetic than real issues, so low priority. I was going to cover them here, but
> this will just confuse things and would deserve its own topic/discussion.
I'm re-proposing that we scrap groups entirely in favor of metapackages. (I
think I send a message to this list about this over a year ago.)
A metapackage would consist of an empty package (i.e. no installable files
other than pacman metadata). The package would list the members of the
metapackage as optdepends.
For this to be useful, the following would be needed:
* optdepends dialogue: this would be (almost?) identical to the current group
dialogue... the user could then either select all members of the metapackage
or just the ones he wants, exactly as groups currently work
* user-selected optdepends would need to be handled by pacman: an easy way to do
this is to add an extra directory to the database alongside "local" and
"sync" to store data about user-selected optdepends ("soft deps", as opposed
to "hard deps" specified by "depends"). For the sake of example, let's call
this directory "custom". When a user installs an optdepend specifically for
package "foo" (i.e. makes it a "soft dep" of "foo"), the directory
"custom/foo" would be created in the database. Inside that directory, a file
named "depends" would be created. This file would be analogous to the
"depends" file in the "local" and "sync" directories.
"custom/foo/depends" would contain a section named "%DEPENDS%" and in that
section it would list all "soft deps" installed by the user for "foo".
When pacman needs to check the dependencies of any package, it loads the
"depends" file in "sync" or "local", depending on the operation. At this
point, pacman has an internal list of the package's dependencies. It should
then check for the existence of "custom/$pkgname/depends". If that file
exists, it should be loaded and all packages listed in that file's %DEPENDS%
section (the optdepends specified by the user) should be added to the
aforementioned internal list of dependencies.
At that point, all optdeps specified by the user will be treated as though
there were deps of the package and pacman can manage them without any further
changes. The overhead of testing for the existence of a file should be
negligible. By keeping this in a separate directory in the database ("custom"
in this example), the "local" and "sync" databases are unaffected, i.e. no
files in either of the existing databases would need to be changed, plus
"custom" could be extended later if necessary (e.g. to allow users to
associate files with packages, e.g. config files).
Other benefits would be automatic upgrades... currently a user has to
manually check if a new package is added to a group and anyone can place
their own packages in any group. With metapackages as specified above, only
the maintainer of the metapackage can control which packages are "included"
in it, and when the maintainer adds a new package to the group, the "new
optdep" hook would inform the user (and maybe even trigger the
* The optdep dialogue should be accessible for managing optdeps locally, i.e.
when not installing, e.g. "pacman -Q --optdeps foo". This should also let the
* An "--asoptdepsfor" (or "--assoftdepsfor") option should be added to make
packages "soft deps" of another package, e.g. "pacman --assoftdepsfor foo bar
baz" would make "bar" and "baz" "soft deps" of foo.
* An "old optdep" hook could inform the user when an optdep installed as a
"soft dep" has been removed from a package, e.g. "foo" used to list "bar" as
an optdep so the user installed "bar" as a "soft dep", but now "foo" has
dropped "bar" as an optdep, so a message is display upon upgrade.
* Files and dirs in "custom" should be removed when they are empty.
* "groups" can be completely replaced with something that follows as a natural
consequence of pacman's standard behavior with all benefits that it brings
* "soft deps" would not need to be limited to optdepends, thus users could
easily manage their own custom dependencies
I would really like to hear some thoughts about this approach from the devs.
More information about the pacman-dev